We Keep Coding

Static class vs Class with constructor performance [duplicate]

This question already has answers here:
Performance of static methods vs instance methods
(3 answers)
Closed 6 years ago.
Performance-wise is there any difference on doing this?:
public static Class StaticTestClass()
{
public static void Function(object param) => //Do stuff with "param"
}
and this:
public Class ConstructedTestClass()
{
private object classParam;
public ConstructedTestClass(object param)
{
classParam = param;
}
public void Function() => //Do stuff with "classParam"
}
I think that there wouldn't be any performance differece if done it one single time, but what If I have to do it many times, and call Function() many times?
Will having many instances of ConstructedTestClass have a memory impact?
And will calling Function withing StaticTestClass with the parameter have any performance impact?
PS: There are similar questions to this but I can't find one that adresses performance upon many calls.
EDIT: I did some tests and this are the results:
With 1000000000 iterations and Creating a ConstructedClass each iteration.
Static way: 72542ms
Constructed way: 83579ms
In this case the static way is faster, then I tried not creating a class each time Function() is called, this are the results: [100000000 samples]
Static way: 7203ms
Constructed way: 7259ms
In this case there's almost no difference so I guess I can do whatever I like the most since i wont be creating 1000000000 instances of the class.

Technically yes, the static method will be slightly faster per call, because a static method doesn't have to check and see if the object it's attached to (because it's not) has been instantiated. This happens behind the scenes. (Technically there will be other slight overhead to set up the object etc.)
This is not a really good reason under most circumstances to choose one over the other though. They have different purposes. The a static method can't maintain state of internal variables like an object can etc.
In your case I would probably pick the static method. Based on the code you show, you don't have a real need to maintain a reference to the object you want to do something to. Perform a function on it, and be done with it.
With the other approach you have to create an object, then call the method. Furthermore the way it's set up, you have to instantiate a new object for each target object you have to perform the action on, because there is a reference stored in a private variable the method acts on. To me this would be more confusing from a readability perspective.

One difference is, that the generated objects have to be garbage collected. That overhead doesn't occur for the static call.
I tested it for 100000000 iterations:
static version takes ~0.7 seconds
non-static version (creating the instance one time and call the method n
times) takes ~ 0.7 seconds.
non-static version (creating one instance per call) takes ~1.4 seconds.

Static members and instance methods for multiple requests at the same time

If I define an object like a logger object as static in a class, then call a method like the following:
public class Manager
{
private static ClientLogManager log = new ClientLogManager();
public void Log(string Message)
{
log.Debug(string Message);
}
}
This is defined in a class library project.
My understanding is that the static variable is shared between all requests for this application, so the log object is shared. However the method Debug itself is not static, but the object is static, so there will be only one instance of this method. Is that correct?
If a lot of users are calling this code at the same time, if 2 requests are calling the log.Debug method at the same time, can the message of the 2nd request overwrite the message of the 1st request?
Also, is it better to replace this with a Singleton? wouldn't it be one Singleton object per request?
Here is the ClientLogManager code
public class ClientLogManager
{
#region Member Variables
private static readonly ILog _log = LogManager.GetLogger(typeof(ClientLogManager));
#endregion
#region Constructors
public ClientLogManager()
{
}
#endregion
#region Public Methods
public void Debug(string message)
{
_log.Debug(message);
}
#endregion
}

If a lot of users are calling this code at the same time, if 2 requests are calling the log.Debug method at the same time, can the message of the 2nd request overwrite the message of the 1st request?
Yes, unless the logger is specifically written to support this. Most loggers are designed to support this, so unless you rolled your own from scratch chances are it will synchronize all writes internally (so that you don't have to). If you are unsure you should check the documentation for the specific logger you are using to see if it will support or break when written to simultaneously.

"My understanding is that the static variable is shared between all requests for this application, so the log object is shared."
Correct, there exists only 1 instance of a static member per AppDomain.
"However the method Debug itself is not static, but the object is static, so there will be only one instance of this method. Is that correct?"
The statement in itself is correct, but...
What it boils down to is this:
Both static and instance methods "exist" only once in memory, the difference is that
a static method does not need an instance of the class it's declared on in order to
be executed, whereas an instance method does.
If multiple requests can be handled concurrently, they have to be executed on different
threads. Each thread has its own call stack, and if you use a thread to perform a method
call on, the arguments passed to that method are placed on the call stack of that thread.
This means that, as long as the argument is either a valuetype (such as an int) or an
immutable type (such as in this case, a string) it cannot be modified by another thread
(because it is either not visible from another thread, or not modifyable).
Hence, you don't have to worry that the messages get mixed up inside your Manager.Log() or ClientLogManager.Debug() method.
So, both your current Manager and ClientLogManager implementations are thread-safe (at least, if the _log instance is thread-safe).
Once you start declaring non-static member variables in your Manager class, and
you're going to use them in Manager.Log(), then it is no longer thread-safe:
The same Manager instance could then be accessed by multiple threads, and once they
all start writing in the same member variable, you're in trouble...
I hope this clarifies things a bit.

What Makes a Method Thread-safe? What are the rules?

Are there overall rules/guidelines for what makes a method thread-safe? I understand that there are probably a million one-off situations, but what about in general? Is it this simple?
If a method only accesses local variables, it's thread safe.
Is that it? Does that apply for static methods as well?
One answer, provided by #Cybis, was:
Local variables cannot be shared among threads because each thread gets its own stack.
Is that the case for static methods as well?
If a method is passed a reference object, does that break thread safety? I have done some research, and there is a lot out there about certain cases, but I was hoping to be able to define, by using just a few rules, guidelines to follow to make sure a method is thread safe.
So, I guess my ultimate question is: "Is there a short list of rules that define a thread-safe method? If so, what are they?"
EDIT
A lot of good points have been made here. I think the real answer to this question is: "There are no simple rules to ensure thread safety." Cool. Fine. But in general I think the accepted answer provides a good, short summary. There are always exceptions. So be it. I can live with that.

If a method (instance or static) only references variables scoped within that method then it is thread safe because each thread has its own stack:
In this instance, multiple threads could call ThreadSafeMethod concurrently without issue.
public class Thing
{
public int ThreadSafeMethod(string parameter1)
{
int number; // each thread will have its own variable for number.
number = parameter1.Length;
return number;
}
}
This is also true if the method calls other class method which only reference locally scoped variables:
public class Thing
{
public int ThreadSafeMethod(string parameter1)
{
int number;
number = this.GetLength(parameter1);
return number;
}
private int GetLength(string value)
{
int length = value.Length;
return length;
}
}
If a method accesses any (object state) properties or fields (instance or static) then you need to use locks to ensure that the values are not modified by a different thread:
public class Thing
{
private string someValue; // all threads will read and write to this same field value
public int NonThreadSafeMethod(string parameter1)
{
this.someValue = parameter1;
int number;
// Since access to someValue is not synchronised by the class, a separate thread
// could have changed its value between this thread setting its value at the start
// of the method and this line reading its value.
number = this.someValue.Length;
return number;
}
}
You should be aware that any parameters passed in to the method which are not either a struct or immutable could be mutated by another thread outside the scope of the method.
To ensure proper concurrency you need to use locking.
for further information see lock statement C# reference and ReadWriterLockSlim.
lock is mostly useful for providing one at a time functionality,
ReadWriterLockSlim is useful if you need multiple readers and single writers.

If a method only accesses local variables, it's thread safe. Is that it?
Absolultely not. You can write a program with only a single local variable accessed from a single thread that is nevertheless not threadsafe:
https://stackoverflow.com/a/8883117/88656
Does that apply for static methods as well?
Absolutely not.
One answer, provided by #Cybis, was: "Local variables cannot be shared among threads because each thread gets its own stack."
Absolutely not. The distinguishing characteristic of a local variable is that it is only visible from within the local scope, not that it is allocated on the temporary pool. It is perfectly legal and possible to access the same local variable from two different threads. You can do so by using anonymous methods, lambdas, iterator blocks or async methods.
Is that the case for static methods as well?
Absolutely not.
If a method is passed a reference object, does that break thread safety?
Maybe.
I've done some research, and there is a lot out there about certain cases, but I was hoping to be able to define, by using just a few rules, guidelines to follow to make sure a method is thread safe.
You are going to have to learn to live with disappointment. This is a very difficult subject.
So, I guess my ultimate question is: "Is there a short list of rules that define a thread-safe method?
Nope. As you saw from my example earlier an empty method can be non-thread-safe. You might as well ask "is there a short list of rules that ensures a method is correct". No, there is not. Thread safety is nothing more than an extremely complicated kind of correctness.
Moreover, the fact that you are asking the question indicates your fundamental misunderstanding about thread safety. Thread safety is a global, not a local property of a program. The reason why it is so hard to get right is because you must have a complete knowledge of the threading behaviour of the entire program in order to ensure its safety.
Again, look at my example: every method is trivial. It is the way that the methods interact with each other at a "global" level that makes the program deadlock. You can't look at every method and check it off as "safe" and then expect that the whole program is safe, any more than you can conclude that because your house is made of 100% non-hollow bricks that the house is also non-hollow. The hollowness of a house is a global property of the whole thing, not an aggregate of the properties of its parts.

There is no hard and fast rule.
Here are some rules to make code thread safe in .NET and why these are not good rules:
Function and all functions it calls must be pure (no side effects) and use local variables. Although this will make your code thread-safe, there is also very little amount of interesting things you can do with this restriction in .NET.
Every function that operates on a common object must lock on a common thing. All locks must be done in same order. This will make the code thread safe, but it will be incredibly slow, and you might as well not use multiple threads.
...
There is no rule that makes the code thread safe, the only thing you can do is make sure that your code will work no matter how many times is it being actively executed, each thread can be interrupted at any point, with each thread being in its own state/location, and this for each function (static or otherwise) that is accessing common objects.

It must be synchronized, using an object lock, stateless, or immutable.
link: http://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html

C# static garbage collector?

I have a simple class which has a static constructor and a instance constructor. Now when i initialized the class , both static and instance constructor are called. Only static is referred once in a application domain . Can i again call the same class initialization and static constructor initialize again? I have tried but it didn't happen? Is there any way we can call static constructor again in main() method after using garbage collection on the class.
Here is the code:
public class Employee
{
public Employee()
{
Console.WriteLine("Instance constructor called");
}
static Employee()
{
Console.WriteLine("Static constructor called");
}
~Employee()
{
//Dispose();
}
}
Now in main method call:
static void Main(string[] args)
{
Employee emp = new Employee();
Employee emp = new Employee();
}
Output:
Static constructor called
Instance constructor called
Instance constructor called
Now the static didn't called again. Because it is called once in application domain. But is their any way we could call it again without unloading application domain. Can we use GC class over here?
Thanks.
Pal

Unless you prod it with reflection, the static constructor (or more generally, the type initializer) is only executed once per concrete class, per AppDomain.
Note that for generics, using different type arguments you'll get different concrete classes:
public class Foo<T>
{
Foo()
{
Console.WriteLine("T={0}", typeof(T));
}
public static void DummyMethod() {}
}
...
Foo<int>.DummyMethod(); // Executes static constructor first
Foo<string>.DummyMethod(); // Executes static constructor first
Foo<string>.DummyMethod(); // Type is already initialized; no more output

Not possible. The CLR keeps an internal status bit that tracks whether the type initializer was started. It cannot run again. That status bit is indeed stored in the loader heap as part of the AppDomain state. The workaround is simple, just add a static method to the class.

The point of a constructor is to put things into a desired initial valid state.
An instance constructor puts an instance into an initial valid state.
An instance constructor that takes arguments puts an instance into a initial valid state that reflects its arguments.
A static constructor puts the type into an initial valid state. E.g. initialising static members used by the class' static methods or shared by all instances.
Ideally all methods will leave the object and the type in a valid state, but constructors differ in being responsible for getting it into one in the first place.
Any attempt to call a constructor twice is therefore a mistake, since "put it into an initial valid state again" isn't something you can logically do twice ("initial" and "again" don't work well in the same clause). We are helped by the compiler (in it refusing to compile) and the language (in there being no way to express this) from doing such a thing.
And, being a logical impossibility it isn't something you can actually want to do (well, I can want to draw a triangle with more than 3 sides, but only to say that I did). This suggests that you are using your constructor to do something other than setting up an initial valid state.
Doing anything other than establishing such a valid state in a constructor is (as is failing to do so) at best an optimisation, quite often a serious design flaw and quite possibly (worse of all because it goes unfixed longer) an attempted optimisation that is really a serious design flaw.
One sign that your attempt at an optimisation is really a design flaw is a desire to call a static constructor more than once, or to call an instance constructor more than once on the same object.
Identify the desired repeatable behaviour, move it into a separate method, and have it called as needed from both the constructor and elsewhere. Then double check your design's logic, as this is quite a serious mistake to find in a class design and suggests you've got deeper problems.

Advantages to Using Private Static Methods

When creating a class that has internal private methods, usually to reduce code duplication, that don't require the use of any instance fields, are there performance or memory advantages to declaring the method as static?
Example:
foreach (XmlElement element in xmlDoc.DocumentElement.SelectNodes("sample"))
{
string first = GetInnerXml(element, ".//first");
string second = GetInnerXml(element, ".//second");
string third = GetInnerXml(element, ".//third");
}
...
private static string GetInnerXml(XmlElement element, string nodeName)
{
return GetInnerXml(element, nodeName, null);
}
private static string GetInnerXml(XmlElement element, string nodeName, string defaultValue)
{
XmlNode node = element.SelectSingleNode(nodeName);
return node == null ? defaultValue : node.InnerXml;
}
Is there any advantage to declaring the GetInnerXml() methods as static? No opinion responses please, I have an opinion.

From the FxCop rule page on this:
After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

When I'm writing a class, most methods fall into two categories:
Methods that use/change the current instance's state.
Helper methods that don't use/change the current object's state, but help me compute values I need elsewhere.
Static methods are useful, because just by looking at its signature, you know that the calling it doesn't use or modify the current instance's state.
Take this example:
public class Library
{
private static Book findBook(List<Book> books, string title)
{
// code goes here
}
}
If an instance of library's state ever gets screwed up, and I'm trying to figure out why, I can rule out findBook as the culprit, just from its signature.
I try to communicate as much as I can with a method or function's signature, and this is an excellent way to do that.

A call to a static method generates a call instruction in Microsoft intermediate language (MSIL), whereas a call to an instance method generates a callvirt instruction, which also checks for a null object references. However, most of the time the performance difference between the two is not significant.
Source: MSDN - https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/79b3xss3(v=vs.110)

Yes, the compiler does not need to pass the implicit this pointer to static methods. Even if you don't use it in your instance method, it is still being passed.

It'll be slightly quicker as there is no this parameter passed (although the performance cost of calling the method is probably considerably more than this saving).
I'd say the best reason I can think of for private static methods is that it means you can't accidentally change the object (as there's no this pointer).

This forces you to remember to also declare any class-scoped members the function uses as static as well, which should save the memory of creating those items for each instance.

I very much prefer all private methods to be static unless they really can't be. I would much prefer the following:
public class MyClass
{
private readonly MyDependency _dependency;
public MyClass(MyDependency dependency)
{
_dependency = dependency;
}
public int CalculateHardStuff()
{
var intermediate = StepOne(_dependency);
return StepTwo(intermediate);
}
private static int StepOne(MyDependency dependency)
{
return dependency.GetFirst3Primes().Sum();
}
private static int StepTwo(int intermediate)
{
return (intermediate + 5)/4;
}
}
public class MyDependency
{
public IEnumerable<int> GetFirst3Primes()
{
yield return 2;
yield return 3;
yield return 5;
}
}
over every method accessing the instance field. Why is this? Because as this process of calculating becomes more complex and the class ends up with 15 private helper methods, then I REALLY want to be able to pull them out into a new class that encapsulates a subset of the steps in a semantically meaningful way.
When MyClass gets more dependencies because we need logging and also need to notify a web service (please excuse the cliche examples), then it's really helpful to easily see what methods have which dependencies.
Tools like R# lets you extract a class from a set of private static methods in a few keystrokes. Try doing it when all private helper methods are tightly coupled to the instance field and you'll see it can be quite a headache.

As has already been stated, there are many advantages to static methods. However; keep in mind that they will live on the heap for the life of the application. I recently spent a day tracking down a memory leak in a Windows Service... the leak was caused by private static methods inside a class that implemented IDisposable and was consistently called from a using statement. Each time this class was created, memory was reserved on the heap for the static methods within the class, unfortunately, when the class was disposed of, the memory for the static methods was not released. This caused the memory footprint of this service to consume the available memory of the server within a couple of days with predictable results.