VMTable lookup caching can be practically useful only for interface calls, since method address resolution is more complex in this case.

So forget about idea #3

// Objects must be different
theObject1 = theObject.Clone();
…
theObject2 = theObject.Clone();

— Loop start —
theObject1.VirtualIncreaseLong();
…
theObjectN.VirtualIncreaseLong();

// Now we’re rolling all the references to ensure all of them are changed
theObjectT = theObjectN;
theObjectN = theObjectN-1;
theObjectN-1 = theObjectN-2;
…
theObject2 = theObject1;
theObject1 = theObjectT;
— Loop end —

Surely: allocation is ~ 4-5 times more costly than vmcall.

That’s wrong. JITter emits different code for callvirt that actually invoking non-virtual method.

The main reason to always emit callvirt by C# is that actually referenced method can be replaced by virtual in future versions of assembly it is declared in, so using callvirt is safe from the point of compatibility.

1) I’d recommend to enroll the main loop 10 times at least. Increment + comparison cost is comparable to VTable lookup.

2) EnsureThatEverythingHasBeenJitted actually doesn’t work: TestXxxMethod isn’t jitted after this call, and consequently, Stopwatch code isn’t jitted as well. Not really important in your case (2…5 sec. is pretty large time in comparison to JITter costs), but I’d anyway call TestXxxMethods from EnsureThatEverythingHasBeenJitted, but with small numberOfTimes value.

3) If 1 & 2 won’t affect on result, I’d try to use a bit different code to avoid possible VTable lookup caching:
theObject1 = (MyObject) (object) theObject;
…
theObjectN = (MyObject) (object) theObject;
— Loop start —
theObject1.VirtualIncreaseLong();
…
theObjectN.VirtualIncreaseLong();
— Loop end —

Not fully sure if this will work, since a lot depends on compiler here. But it’s clear that original code is simply ideal for VTable lookup caching.

there is still a difference between using callvirt for a non-virtual method and for a virtual method AFAIK. When using callvirt with a virtual function, the CLR still does a null reference check (and throws a NullReferenceException if the instance reference is null) while it does the null check and an aditional lookup of the correct virtual method to call in case of a virtual method. I had always been told that that was supposedly the reason why there should be a performance difference. AFAIK, the call instruction is only used for static methods.

If there is indeed no performance cost at all, then certain Microsoft people really need to stop using that as an argument . And it should, in fact be removed as a reason why not to use virtual methods from the Framework Design Guidelines book that they publish. And they might want to update the CLR Via C# book regarding this as well

Basically, there are two IL instructions to call a method, “call” and “callvirt”. Since the c# compiler is emitting “callvirt” for both virtual and non-virtual method calls, you don’t see any difference in performance between the virtual and non-virtual call.

Once a vtable is loaded for a certain type, I imagine the performance cost to be pretty low.

i tried it with new instances for each call, the performance measurements of calling the methods were pretty much identical

To be able to measure the performance correctly you would need multiple classes… maybe quicknet it?

i don’t see anything in that post that explains the behavior i’m seeing here

I suppose that this might be interesting for you: The cost of method calls (http://tips.x-tensive.com/2008/10/method-call-performance.html)

Virtual method calls are compared with delegate method calls as well as with interface method calls. Moreover, delegate creation & generic method calls are also measured. Take a look at it.

Anders Hejlsberg discusses his reasons for making it non-virtual by default here:
http://www.artima.com/intv/nonvirtual.html

No matter, you’d have to be writing a seriously performance-sensitive application for it to make any difference – in which case you’d probably not be using a language with automatic garbage collection anyway ….