0

I was developing an web appliation and I created a method which returns Dataset. While checking the performance of the appliacation, I got the message like "Methods which do not access instance data or call instance methods can be marked as static.

I don't know why I need to do this.

Thanks in advance!

ABH
  • 3,391
  • 23
  • 26
ranga nathan
  • 163
  • 3
  • 17
  • just post me code. if we look code this problem seems pretty simple. – Vetrivel mp Mar 27 '12 at 07:32
  • See [this question](http://stackoverflow.com/questions/731763/should-c-sharp-methods-that-can-be-static-be-static). – Matt Mar 27 '12 at 07:32
  • 1
    [Neither use static connections](http://stackoverflow.com/questions/9705637/executereader-requires-an-open-and-available-connection-the-connections-curren/9707060#9707060) nor static DataSets, least of all in a web-application. – Tim Schmelter Mar 27 '12 at 07:37
  • @TimSchmelter this is talking about static methods, not static fields. – sq33G Mar 27 '12 at 11:34
  • @sq33G: I've only commented because it's unclear whether OP only used a static method as factory or used/initiliazed static fields there. – Tim Schmelter Mar 27 '12 at 11:36

4 Answers4

3

Quoting the MSDN:

"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."

http://msdn.microsoft.com/en-us/library/ms245046.aspx

That said, any performance difference will probably be negligible (as others have mentioned). If you know for sure that the method will only be called when you have an instance of your object, there's really no point in making it static.

Though this isn't the intention of the rule, when I see this warning (from either Code Analysis or Resharper), I make sure that the method it's warning me about is really where it belongs. Sometimes the fact that a method doesn't reference anything in the class can signify that it really doesn't belong in that class.

Duane Theriot
  • 2,135
  • 1
  • 13
  • 16
2

I don't know why i need to do this.

You don't need to, and it probably won't make a significant performance difference, if any. However, you might want to consider doing it anyway. If the methods aren't virtual for polymorphism reasons, and they're not using anything about a particular instance, then I'd make them static to show that they're not really tied to any particular instance.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Yes, but maybe its not correct from a design point of view to call these methods without a corresponding instance ! You might have some logic tied up to the creation of those objects, so if you mark some methods as static, you just loose all of that. – squelos Mar 27 '12 at 07:37
  • @squelos: It's not clear what you mean by "logic tied up to the creation of those objects" - but I'd argue that if constructing an instance is the only way to make a static method *which doesn't touch any instance data* valid, there's something decidedly wrong with the design. – Jon Skeet Mar 27 '12 at 07:38
0

All other things being equal non-virtual calls are slightly faster so converting to a static method should produce a performance gain. However, static methods have fundamentally different behaviour - especially with respect to multithreaded code - so you should approach this carefully.

Ian Gilroy
  • 2,031
  • 16
  • 14
  • What do you view as their "fundamentally different behaviour" when it comes to multithreaded code? Typically you try to make static methods thread-safe whereas instance methods don't *normally* need to be thread-safe, but that's a matter of implementation - not a matter of how they behave fundamentally. Changing a static method to an instance method won't change how thread-safe it is or vice versa. (There's a difference if you're using an attribute to synchronize, admittedly, but that's an edge case.) – Jon Skeet Mar 27 '12 at 07:36
  • You're right - I shouldn't have linkedI guess I meant that there's a fundamental difference between the two in that one operates on a specific instance of the type and the other doesn't. That difference – Ian Gilroy Mar 27 '12 at 08:10
  • Right, that's absolutely the difference to focus on. Now here we have a method which is identified as *not accessing anything to do with a particular instance*... which sounds like it's a good fit for being a static method. – Jon Skeet Mar 27 '12 at 08:15
0

You dont necessarily need to do it. Actually, its pretty stupid advice in my opinion, because it encourages you to mark it as static, while you might not want it static !

Static methods just make the method accessible even without instanciating an object. Consider the following snippet : 

Foo _bar = new Foo();
_bar.RandomMethod();// not necessarily static


Foo.RandomMethod();//Foo is the class, and RandomMethod is static.

My advice would be, dont follow that message, and just do as your design is telling you :). If you feel its right to require an object, dont mark it as static. If you find its coherent to be able to call this method without an object, mark is as static

squelos
  • 1,189
  • 6
  • 16