what's better Static Methods or Instace Methods

[David]

My AIM is the performance, so what is better to use, static method or
instance method? and why?


Thanks a lot

 

[Jon Skeet [C# MVP]]

My AIM is the performance, so what is better to use, static method or
instance method? and why?

I doubt there'll be much difference, at least if the method isn't
virtual. I very much doubt that the method call itself will be the
bottleneck.

Use whatever is more natural in the design - if something naturally
operates on an instance, use an instance method. If it doesn't, use a
static method.

 

[Girish bharadwaj]

One can argue that the initial creation of the object required for instance
might add a few extra IL than the call to a static.
For a test code as shown below,

using System;

class Test
{
public Test(){}
public void CallMe(){}
public static void CallMe_Static(){}

public static void Main(){
CallMe_Static();
Test t = new Test();
t.CallMe();
}
}

here is the IL generated for Main.

This is all it took to call CallMe_Static().

call void Test::CallMe_Static()


Here is the IL it needed to actually create the object and call the method.
In most applications, any time spent in the creation would probably be
offset by the actual call itself.

newobj instance void Test::.ctor() Create object
stloc.0 store it in a variable at index 0
ldloc.0 load the value to evaluation stack
callvirt instance void Test::CallMe() call the method.

I am not sure if the optimization by the IL to machine code might have
intelligence to optmize away things here. But, as you can see, all things
being equal, its probably cheaper to call Static methods.

 

[Matt Berther]

Hello Girish,

One could also argue that this leads to a very sloppy design that violates one of the tenets of OOP. Specifically, you have no encapsulation, inheritance *or* polymorphism with a purely static class.

 

[Jon Skeet [C# MVP]]

One can argue that the initial creation of the object required for instance
might add a few extra IL than the call to a static.

Yes - I had assumed the creation of the object had been factored in
elsewhere, and that the OP was only asking about the calling of
methods, rather than the creation of objects as well.

Calling an instance method *does* have the tiny extra overhead of
checking that the target isn't null, admittedly.

 

[Richard Blewett [DevelopMentor]]

well at this point we are arguing over minutae that will be completely irrelevant when the method actually *does* something. Although academically interesting about the one or two IL instructions these sort of things are pretty much never where performance issues are based. It only leads people into premature optization (spending time optimizing things that are probably not a bottleneck anyway).

The fundemental thing about static and instance methods is that they have different use cases, not that one is faster than the other.

Regards

Richard Blewett - DevelopMentor

http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

One can argue that the initial creation of the object required for instance
might add a few extra IL than the call to a static.

Yes - I had assumed the creation of the object had been factored in
elsewhere, and that the OP was only asking about the calling of
methods, rather than the creation of objects as well.

Calling an instance method *does* have the tiny extra overhead of
checking that the target isn't null, admittedly.

--
Jon Skeet - <[email protected]>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.framework]

 

[Jon Skeet [C# MVP]]

well at this point we are arguing over minutae that will be
completely irrelevant when the method actually *does* something.
Although academically interesting about the one or two IL
instructions these sort of things are pretty much never where
performance issues are based. It only leads people into premature
optization (spending time optimizing things that are probably not a
bottleneck anyway).

The fundemental thing about static and instance methods is that they
have different use cases, not that one is faster than the other.

Absolutely agreed (see my first post).

 

[Girish bharadwaj]

I was not arguing. And I agree that they are different use cases. Well, I
just wanted to point out that there is some cost involved. Whether or not
its relevant depends on poster's needs.


--
Girish Bharadwaj
http://msmvps.com/gbvb

well at this point we are arguing over minutae that will be completely

irrelevant when the method actually *does* something. Although academically
interesting about the one or two IL instructions these sort of things are
pretty much never where performance issues are based. It only leads people
into premature optization (spending time optimizing things that are probably
not a bottleneck anyway).

The fundemental thing about static and instance methods is that they have

different use cases, not that one is faster than the other.

Regards

Richard Blewett - DevelopMentor

http://staff.develop.com/richardb/weblog

One can argue that the initial creation of the object required for instance
might add a few extra IL than the call to a static.

Yes - I had assumed the creation of the object had been factored in
elsewhere, and that the OP was only asking about the calling of
methods, rather than the creation of objects as well.

Calling an instance method *does* have the tiny extra overhead of
checking that the target isn't null, admittedly.

--
Jon Skeet - <[email protected]>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.framework]

 

[Girish bharadwaj]

Umm, While I agree that it does stop you from having any of the OOness in
your class, I am not sure if its sloppy design just because its static.

I can think of many use cases where a static method would just do fine for
me. They serve the same purpose as global functions used to in C++. I can do
it better in C# since i can encapsulate them within an assembly.


--
Girish Bharadwaj
http://msmvps.com/gbvb

Hello Girish,

One could also argue that this leads to a very sloppy design that violates

one of the tenets of OOP. Specifically, you have no encapsulation,
inheritance *or* polymorphism with a purely static class.

 

[Richard Blewett [DevelopMentor]]

Refusing to let this rest ;-)

If the cost of static as opposed to instance invocation is important to the posters needs then they probably shouldn't be using .NET for their application - unmanaged C or C++ would be a better alternative.

Regards

Richard Blewett - DevelopMentor

http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I was not arguing. And I agree that they are different use cases. Well, I
just wanted to point out that there is some cost involved. Whether or not
its relevant depends on poster's needs.


--
Girish Bharadwaj
http://msmvps.com/gbvb

well at this point we are arguing over minutae that will be completely

irrelevant when the method actually *does* something. Although academically
interesting about the one or two IL instructions these sort of things are
pretty much never where performance issues are based. It only leads people
into premature optization (spending time optimizing things that are probably
not a bottleneck anyway).

The fundemental thing about static and instance methods is that they have

different use cases, not that one is faster than the other.

Regards

Richard Blewett - DevelopMentor

http://staff.develop.com/richardb/weblog

One can argue that the initial creation of the object required for instance
might add a few extra IL than the call to a static.

Yes - I had assumed the creation of the object had been factored in
elsewhere, and that the OP was only asking about the calling of
methods, rather than the creation of objects as well.

Calling an instance method *does* have the tiny extra overhead of
checking that the target isn't null, admittedly.

--
Jon Skeet - <[email protected]>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.framework]

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.framework]

 

[Girish bharadwaj]

Fine.!

--
Girish Bharadwaj
http://msmvps.com/gbvb

Refusing to let this rest ;-)

If the cost of static as opposed to instance invocation is important to

the posters needs then they probably shouldn't be using .NET for their
application - unmanaged C or C++ would be a better alternative.

 

[Matt Berther]

Hello Girish,

What Im saying is that an occassional static method is fine, but if you make a purely static class, it would tend to lead to a sloppy design.

 

[Richard Blewett [DevelopMentor]]

So you consider the System.Math class bad design?

Regards

Richard Blewett - DevelopMentor

http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hello Girish,

What Im saying is that an occassional static method is fine, but if you make a purely static class, it would tend to lead to a sloppy design.

--
Matt Berther
http://www.mattberther.com

Umm, While I agree that it does stop you from having any of the OOness
in your class, I am not sure if its sloppy design just because its
static.

I can think of many use cases where a static method would just do fine
for me. They serve the same purpose as global functions used to in
C++. I can do it better in C# since i can encapsulate them within an
assembly.


one of the tenets of OOP. Specifically, you have no encapsulation,
inheritance *or* polymorphism with a purely static class.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.framework]