Speed of virtual call in C# vs C++

Question

I seem to recall reading somewhere that the cost of a virtual call in C# is not as high, relatively speaking, as in C++. Is this true? If so - why?

Answer 1

The cost of a virtual call in C++ is that of a function call through a pointer (vtbl). I doubt that C# can do that one faster and still being able to determine object type at runtime...

Edit: As Pete Kirkham pointed out, a good JIT might be able to inline the C# call, avoiding a pipeline stall; something most C++ compilers cannot do (yet). On the other hand, Ian Ringrose mentioned the impact on cache usage. Adding to that the JIT itself running, and (strictly personally) I wouldn't bother really unless profiling on the target machine under realistic workloads has proven the one to be faster than the other. It's micro-optimization at best.

Answer 2

For JIT compiled languages (I don't know if CLR does this or not, Sun's JVM does), it's a common optimisation to convert a virtual call which has only two or three implementations into a sequence of tests on the type and direct or inline calls.

The advantage of this is that modern pipelined CPUs can use branch prediction and prefetching of direct calls, but an indirect call (represented by a function pointer in high level languages) often results in the pipeline stalling.

In the limiting case, where there is only one implementation of the virtual call and the body of the call is small enough, the virtual call reduced to purely inline code. This technique was used in the Self language runtime, which the JVM evolved from.

Most C++ compilers don't perform the whole program analysis required to perform this optimisation, but projects such as LLVM are looking at whole program optimisations such as this.

Answer 3

I guess this assumption is based on JIT-compiler, meaning that C# probably converts a virtual call into a simple method call a bit before it is actually used.

But it's essentially theoretical and i would not bet on it !