BlackWaspTM

This web site uses cookies. By using the site you accept the cookie policy.This message is for compliance with the UK ICO law.

Performance
.NET 2.0+

Speed Test: Static vs Instance Methods

C# allows the creation of instance members and static members. Instance members are available when an instance of the class is created and have access to the object's data. Static members do not require an object so do they increase performance?

Test Description

Purpose

The test was created to compare the performance of static methods and instance methods, determining the performance penalty of using one over the other. Developers who use the code analysis tool, "FxCop", may have encountered rule CA1822, which suggests that static methods are faster than their equivalent instance members. The rule is as follows:

"Methods which do not access instance data or call instance methods can be marked as static. After doing so, the compiler will emit non-virtual call sites to these members which will prevent a check at runtime for each call that insures 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."

Test Process Functionality

Three tests were executed, each being run one billion times in a for-loop. For the first test, an integer value was incremented within the loop but no calls to any methods were made. This allowed the duration of the loop to be measured and used as a baseline figure. The second test measured the performance of an instance method. The same increment operation was undertaken but this time the loop called a method for each iteration. The final test was identical to the second except that a static method was called. For all three tests, the duration of the billion iterations was measured in milliseconds.

Timing

The timing of the three tests was undertaken using the Stopwatch class. The tests were performed repeatedly and the mean average of the results calculated.

Test Conditions

Hardware

The test results included below are those produced using an Athlon64 X2 Dual Core Processor running at 1.9GHz with 4GB RAM. These tests are indicative of further relative test results that were carried out on a variety of hardware.

The tests were executed using two operating systems, each with the latest service packs and patches. These were:

  • Windows Vista Home Premium
  • Windows 7 Enterprise

Results

Raw Results

This table shows the timings for the three tests, for one billion iterations rounded to the nearest millisecond.

Time
No Calls1856ms
Instance Method Calls4318ms
Static Method Calls4184ms

Adjusted Results

This next table shows the results for the instance and static methods adjusted to remove the time that can be attributed to the loop and the increment operations. It shows a performance penalty of 134ms on the primary test hardware for one billion iterations. This represents a 5.76% performance penalty for instance method calls over their equivalent static calls.

Time
Instance Method Calls2461ms
Static Method Calls2327ms
Instance Method Performance Penalty134ms
Instance Method Performance Penalty (%)5.76%

Conclusion

The results show that calls to static methods are indeed faster than the equivalent calls to instance methods. However, the penalty for using instance methods is minor and should only be noticeable when making many billions or trillions of calls. If the software that you are developing is performance critical, is may be worthwhile converting some instance members to static members or refactoring to longer methods to remove some calls. This is likely to decrease the readability and maintainability of the code so should be approached with caution.

In most situations the performance penalty will be negligible. It is usually more appropriate to have clean, readable code with slightly lower performance. It may be worthwhile changing private instance methods that do not need access to the class' state to static, as these can easily be reverted at a later time. More visible members, with protected, internal or public scope, should be considered more carefully as there is the possibility of breaking compatibility with other software when changing between static and instance methods.

2 July 2010