Geeks With Blogs
Dynamic Concepts (in) Development Musings of TheCPUWizard

First a disclaimer; this post is about micro-optimization of C# programs and does not apply to most common scenarios - but when it does, it is important to know.

Many developers are in the habit of declaring member virtual to allow for future expansion or using interface based designs1. Few of these developers think about what the runtime performance impact of this decision is.

A simple test will show that this decision can have a serious impact. For our purposes, we used a simple loop to time the execution of 1 billion calls to both non-virtual and virtual implementations of a method that took no parameters and had a void return type:

Direct Call:     1.5uS
Virtual Call:   13.0uS

The overhead of the call increased by nearly an order of magnitude!

Once again, it is important to realize that if the method does anything of significance then this ratio drops quite quickly. If the method does just 1mS of work, then the differential only accounts for a 1% decrease in performance. Additionally the method in question must be called thousands of times in order to produce a meaqsurable impact at the application level.

Yet let us consider a situation such as the per-pixel processing of a graphics processing application. Here we may have a method which is called millions of times and even the slightest increase in overhead can have significant ramification. In this case using either explicit virtuals or interface based constructs is likely to be a mistake.

In conclusion, good design principles should always be the driving force behind descisions such as these; but remember that these decisions do not come for free.


1) When a concrete class member implements an interface it does not need to be explicitly marked as virtual (unless, of course, it is to be overriden in a derived concerete class). Nevertheless, when accessed via the interface it behaves exactly as if it had been marked as virtual. 

Posted on Thursday, May 6, 2010 8:46 PM Developers Notes | Back to top

Comments on this post: Interfaces and Virtuals Everywhere????

# re: Interfaces and Virtuals Everywhere????
Requesting Gravatar...
This is very interesting and definitely warrants more research. I often push for interfaces in my designs. I need to investigate to see when that recommendation needs to be avoided.

Thanks for sharing
Left by Nick Harrison on May 07, 2010 2:56 PM

# re: Interfaces and Virtuals Everywhere????
Requesting Gravatar...
I would however encourage you not to worry about these micro-optimizations until they prove necessary. A pixel processor is a very specific use case and I wouldn't avoid virtual methods elsewhere just because of a minor performance hit. Flexible, maintainable code > faster code in most scenarios (since cost of hardware <<< cost of developer time).
Left by Ryan on Nov 18, 2010 12:50 PM

# re: Interfaces and Virtuals Everywhere????
Requesting Gravatar...
Ryan, you are 100% correct, which is why I posted (in bold) the disclaimer (this post is about micro-optimization of C# programs and does not apply to most common scenarios - but when it does, it is important to know.) at the very sstart of the article.

One way to determine if this approach may help (after making performance measurements to quantify the exact performance of the code in questions as well as its relationship to the lerger picture) is to temporatly create a "straw-man" implementation that does not use virtual functions (i.e. is tailored for a specific concrete class where the methods are not declared as virtual).

If the same measurements applied above show a significant performance improvement, then the techniques I discussed may be appropriate and warrant further investigation and testing.
Left by David V. Corbin on Nov 18, 2010 1:01 PM

Your comment:
 (will show your gravatar)

Copyright © David V. Corbin | Powered by: