Advantages of Static Vs Instance methods?

[Guest]

Hello All,

Can anyone please list me the advantages or disadvantages of instance and
static methods in terms of performance be it either memory consumption or CPU
utilization or any other parameters.

Thank you.

 

[Josh Twist]

Wow, interesting question... if kind of odd.

Performance wise two identical methods implemented as static and
instance would have very (very) little difference in terms of
performance. Certainly nothing to worry about!

The choice of static vs instance methods is typically more about
design. FxCop views the matter fairly simplistically - if your method
doesn't touch any members of the class then it should be static.

As a rule of thumb though, one isn't any faster then the other.

Josh
http://www.thejoyofcode.com/

 

[Guest]

Josh,

You said that instance and static have very little difference in terms of
performance. I am curious to know what that difference is and why?

Thank you.

 

[Josh Twist]

A static method can be called without an instance of the class being
created. e.g.

public class Example
{
public static void Method1()
{
// this is a static method
}

public void Method2()
{
// this is an instance method
}
}

Method1 is a static method of the Example class and is called like
this:
Example.Method1()

Method2 is an instance method of the Example class and is called on an
instance of an Example class:
Example myInstance = new Example();
myInstance();

At the end of the day they're both methods and have no real difference
in terms of performance. Which one to use is a question of design. I
suggest you have a bit of a read up on OOP (Object Oriented
Programming) to help you make these decisions

Josh
http://www.thejoyofcode.com/

 

[Josh Twist]

Oops! the instance method should be called like this:

Example myInstance = new Example();
myInstance.Method2();

NOT!!! Example myInstance = new Example();
myInstance();

Sorry

 

[shannon00000]

The short answer is that static functions are faster. The longer answer below.

The reason why static functions are faster is because of the way programming languages implement objects. For example, suppose class A has function void f() that increments a variable of class A called "counter". When the compiler processes class A is, it creates the code of function f() only once; there is no need to create this code for each instance. Therefore, when the program runs there is only one copy of f() in the memory. When the programmer invokes x.f() and y.f(), how does the code know which copy of f() to run? Well, since there is only one f(), the same function is run all the time. But, you wonder, how does the code know which "counter" to increase. What you do not see is that the function f() actually takes an additional parameter called "this". The "this" pointer tells f() on which instance it should operate. The "this" pointer is added by the compiler by default. Now, in this example, the "this" pointer cannot be resolved at compile time. For example, the program can have an "if-statement" such that the address of x can be one of several options. In other words, the compiler does not know where instance "x" will sit in the memory. Hence, the compiler will have to resolve the address in run time. This takes time.

With static functions, on the other hand, no "this" pointer is passed because the function can be called without an instance. Even if there is an instance x of class A and you call the static function g() of that instance as in x.g(), it will be equivalent to A.g() because g() is not allowed to use any instance variables (only static variables of the class). In other words, there is no resolution process taking place at run time. Hence, static methods are faster and should be chosen when possible.

 

[mderijk]

Thank you for the clear explanation.

Still, i have this question:
Imagine a web application with lots of users that create lots of calls to a certain function.
How are the calls to the function processed?
When the function is static, will the calls be queued as necessary?
And, is it not better for performance to let each user use the function on its own instance, so calls will not be queued (but processed parallel-wise like in threading / asynchronously)?

Thank you in advance for a reply!

 

[saurabh131991]

saurabh

dear,,,, whether each process has separate methods or they share one...it hardly matters...coz they will only be processed in parallel..

 

[cjohn]

static method avoids unnecssary instance

If you want to maintain same state for all instances , you can use static keyword

http://www.4microsoftsolutions.com

 

[drew]

I know this is rather old, but I was doing research on a related topic and came across this inquiry. You really have to separate the implementation from _an_ instance of implementation. While a class's source is all-inclusive, it doesn't accurately reflect the memory organization of a class and what it does. If you think of class and structure instances as holders of field data only, rather than also containing routine implementations and the class's Type instance as a holder of compiled routines, it will help.

_Most_ object implementations (_most_ meaning compiler and runtime environments coupled with whatever languages are used for generation), use something akin to a vtable. This is a table holding member addresses and referencing any associated flags and metadata. A .Net Type referring to a class or structure definition can be thought of as a wrapped view of a) the compiled methods and b) a vtable-ish implementation, providing Reflection class responses for queried members (Properties, Fields, Methods). in vtable methodology, implementations only get compiled once, per class definition, rather than per instance. Instances of classes typically don't have vtables, they just reference the vtable already defined in their corresponding Type. Class and structure instances _do_ have data values for any fields, however. So a static field only occurs once versus an instance field having a corresponding value in each instance, as Shannon said. But a static property or method has only one compiled definition, and each instance property or method also only has one compiled definition, regardless of the number of class/structure instances. Routines don't get copied to each instance, they get reused from the same place with the virtual machine equivalent of an EDI pointer set to the appropriate instances address for declared Me, this, and unprefixed references to fields.

To invoke both static and instance methods requires a table lookup followed by a dereference of that address with whatever parameter data is being passed to be pushed on the stack. I haven't found static methods to perform or be initialized any faster than instance methods, but I've been known to be wrong about thousands of things every day. That said, there _are_ some perceivable performance benefits from using a static method because a) object instantiation (as part of the process flow adding to eating up cpu) isn't required and b) memory usage is lessened (by not having an allocated object instance, such that memory management routines aren't as prevalent). The latter would only be visible at extremely large object usage (number of instances * data size). In any case, static methods are faster to code for.

But also be warned: static methods (in any environment) may also utilize class or member-local static variables making them subject to race conditions - less they implement thread safe synchronization or locking. This isn't specific to static implementations - it happens all the time for instances also. But, _this_ is often overlooked by static method implementers, and usually it is the same implementers who would use a member static variable in the first place. Some programming paradigms require member static variables because at the time of coding there were no other available avenues. Obviously, if there were no other available avenues to avoid member-static variables, there weren't any available avenues to perform method synchronization or locking either (outside of perhaps using a member static lock variable - which still has a small window of exploitation. Seemingly ancient BASIC all the way into VB6 code used this methodology a lot rather than implementing the suggested critical section api calls where available). Thread safe implementations aren't exclusively relegated to static members - the Microsoft-provided List<> class isn't even thread safe. But you really have to be wary of thread safety when using static methods - because such cases can impact the values stored…statically…causing unreliable results for the lifecycle of the Type (which is the lifecycle of the application)…rather than the lifecycle of a class instance. Do you understand the scope of impact, now? <- more important than performance considerations, yes?

No requirement exists in the CLI spec to use vtables/vtable-ish methodology. At any time, they could implement a per-class-instance copy of a compiled method implementation. I wouldn't think that would make much sense (it would bloat process memory drastically)...but stranger things have definitely happened in computing.