43

I assume that public or private static targets must have reduced memory usage, due to the fact that there is only one copy of the static target in memory.

It seems like because a method is static that might make the method a potential point for further optimization by the CLR compiler beyond what is possible with a non-static function. Just a flimsy theory though, so I've come to ask you all.

Do static public or private methods provide any increased performance benefit beyond reduced memory usage?

(Note: I'm not interested in responses that talk on the problems of premature optimization. Certainly that's sound advice I follow everyday, but that does not mean optimization is not necessary at times. (double negative!). Allow me to indulge my curiosity, at the least)

Mark Rogers
  • 96,497
  • 18
  • 85
  • 138

5 Answers5

53

From Static Classes and Static Class Members (C# Programming Guide)

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.

Adriaan Stander
  • 162,879
  • 31
  • 289
  • 284
  • 14
    On modern architectures, the branch predictor eats the null check with near zero overhead. – Sam Harwell Feb 16 '10 at 17:42
  • @280Z28 Well to be accurate some modern platforms (PlayStation 3 does this if my memory serves me Well) eliminate branch prediction enabeling better perfomance for the cost of harder to write programs – Rune FS Feb 16 '10 at 17:59
  • 1
    @Rune FS: On ARM, the checks are implemented with conditionally executed instructions. On the Cell's SPU, you don't have branch prediction, but due to several other concerns, if you plan to execute managed code on the SPU you should be operating primarily on non-null types. I actually wrote a conceptual JIT for the SPU, which focused on a small number of data types useful for high-performance computing and left out runtime null reference checks in favor of static analysis (the Contracts library). – Sam Harwell Feb 16 '10 at 20:21
  • @SamHarwell - ...except for polluting the branch predictor and instruction cache. – TLW Mar 23 '19 at 21:16
24

Aside from what astander said, your question suggests a misunderstanding of what instance methods do. Regardless of whether the function is static or not, there is only one copy of the function code in memory. A non-static method has to be called through an object, but the object does not carry its own private copy of the method. So the memory usage of static and non-static methods is in fact identical, and as others have pointed out, the performance characteristics are nearly identical.

Non-static member variables, however, do exist separately for every object that you create. But it is nearly always a waste of time to worry about that memory usage, unless you actually have a memory-related problem in your program.

JSBձոգչ
  • 40,684
  • 18
  • 101
  • 169
  • "Regardless of whether the function is static or not, there is only one copy of the function code in memory." Thanks, I didn't know that for certain. – Mark Rogers Feb 16 '10 at 17:46
  • 3
    A non-static method has `this` passed in as a hidden parameter, so someone could quibble that it uses more stack space. This doesn't seem particularly significant, though. – Steven Sudit Feb 16 '10 at 17:47
  • 1
    @Steven - if you converted the method into a static, it would then need to have an explicit `this` parameter. – Daniel Earwicker Feb 16 '10 at 18:07
  • @Earwicker: That's correct. Generally, such methods aren't candidates for conversion to static in the first place. – Steven Sudit Feb 16 '10 at 18:13
  • A very critical piece of information that isn't so obvious - `A non-static method has to be called through an object, but the object does not carry its own private copy of the method.`. Glad that you mentioned. +1. – RBT Jan 13 '17 at 00:24
18

This is a little bit off-topic, but none the less important.

The choice of making methods static or instance should not be based on execution time (which anyway seems not to matter). It should be based on whether the method operates on an object. For instance, all the Math.* methods are static while e.g. (most) String.* methods are instance since they operate on a String instance. My personal philosophy: a good design should make up for the few cycles that may be saved elsewhere.

Another view on the subject: I recently worked with a guy who had been told that static methods are evil because they take us back to the dark age of procedural programming and thus shall be avoided at all costs. This resulted in weird examples of classes that required instances for access to methods that had absolutely no interest in the internals of the object.

Phew, it felt good to get that from my hearth.

Christian Madsen
  • 1,688
  • 4
  • 17
  • 30
  • 7
    Simple rule: If a method or property does not access any instance state (`this` and its members), it should probably be static. – Steven Sudit Feb 16 '10 at 19:55
  • 9
    -1 because I'm sick of people who have legitimate optimization/performance questions simply being told "don't do it". Sometimes micro-optimizations **do** matter. – dsimcha Feb 16 '10 at 20:13
  • Occasionally, I like to use small private static functions within non-static classes, so that I can know by the keyword that the method does not directly alter non-static instance variables. But I usually only add the static keyword when the method was not touching an instance variable to begin with. – Mark Rogers Feb 16 '10 at 20:14
  • FxCop advises to make method static if it has no references with class members. – sashaeve Feb 16 '10 at 20:14
  • @dsimcha if you're unaware that a instance method requires the same amount of memory than a static odds are you've not used a profiler (cuz that would show it clearly) with out a highly optimized code base there's no chance that the branch-predicted-away null check is the bottleneck. I Think you ought to upvote again cuz this is clearly not an example where minute optimization would matter – Rune FS Feb 16 '10 at 23:54
  • 3
    Well, he is right about questions involving optimizations. Avoiding premature optimizations is great advice, but people have a hair trigger when giving it out. Unfortunately talking about how bad 'premature optimization' is, doesn't give me new information about the question I asked. The word 'premature' tells you that at some point optimization can become necessary. If you had a performance problem with a method you called millions of times in a row and it didn't touch instance variables. It might make sense to declare it static primarily for style but also for optimization. – Mark Rogers Feb 17 '10 at 15:50
  • 3
    @dsimcha, I fully agree. Micro-optimizations do matter sometimes. However, my experience when developing in a high level language/environment like C#/.Net (and in most cases also for embedded/low level environments) is that a strong design is much more important. This is of cause my own personal experiences, but I believe that lots of programmers share the same experience. – Christian Madsen Feb 17 '10 at 18:52
1

Good answers - basically it doesn't matter, which is the answer to nearly every question of this sort. Even if it did make a difference - If execution time of your program cost a dollar, this sort of issue is likely to cost a fraction of a cent, and it is very likely that there are other things costing a great deal more.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
0

MeasureIt to be certain, but you'll find unless you're creating a globe-spanning ultra-high-volume transaction processing supercomputing cluster, it's not going have an appreciable difference.

Jesse C. Slicer
  • 19,901
  • 3
  • 68
  • 87