3 ms·

As usual, memory access is the expensive operation. If the virtual function is already in L1 cache a virtual function should be only a minor slowdown. If it's a

As usual, memory access is the expensive operation. If the virtual function is already in L1 cache a virtual function should be only a minor slowdown. If it's all the way off in main memory it will be significantly slower. Eric Brumer has a great talk on this: https://channel9.msdn.com/Events/Build/2013/4-329 https://channel9.msdn.com/Events/Build/2013/4-329

eloff 10y ago
Exactly. Calling a virtual function in a tight loop, almost indistinguishable from a direct (non-inlined) function call. Calling a virtual function every now and then, much more expensive, but also not as likely to matter much to the performance of your program on the whole anyway. Still worth noting that every VM like Java or .NET or LuaJIT will optimize for the case that a virtual call usually has only one or two commonly invoked target functions. They will use a conditional fast-path for the common case(s) and fall back to slower virtual calls or less optimized paths for megamorphic calls. I don't know if any C++ compilers do this kind of thing, but I would be surprised if they did not.
- twoodfin 10y ago
  Some C++ compilers support "fast path" devirtualization via profiling feedback: http://hubicka.blogspot.com/2014/04/devirtualization-in-c-part-5-feedback.html http://hubicka.blogspot.com/2014/04/devirtualization-in-c-pa... As you suggest, it's a little misleading to talk about the runtime cost of a virtual or indirect function call in isolation. The most significant cost is often the resulting inability of the compiler to inline and perform further optimizations across the caller and callee.
  - eloff 10y ago
    Nice, I had a feeling they did that, thanks for the link. I fully agree, missed optimization opportunity from not being able to inline is usually a bigger effect, because loops dominate the runtime and that's where those optimizations count.
- exDM69 10y ago
  Virtual function / function pointer calls can still have a big performance impact, especially if it could be inlined away. Compare C standard library qsort with C++ std::sort performance for sorting integers. The difference is huge in favor of std::sort. If you write your own qsort and put it in a header file so the indirect calls can be inlined, they should be equal.
- jheriko 10y ago
  i've seen virtuals completely removed and inlined by gcc when there is enough information for it to do that, and a simple enough use case... probably other compilers are similar.

eloff 10y ago

Exactly. Calling a virtual function in a tight loop, almost indistinguishable from a direct (non-inlined) function call. Calling a virtual function every now and then, much more expensive, but also not as likely to matter much to the performance of your program on the whole anyway. Still worth noting that every VM like Java or .NET or LuaJIT will optimize for the case that a virtual call usually has only one or two commonly invoked target functions. They will use a conditional fast-path for the common case(s) and fall back to slower virtual calls or less optimized paths for megamorphic calls. I don't know if any C++ compilers do this kind of thing, but I would be surprised if they did not.

twoodfin 10y ago
Some C++ compilers support "fast path" devirtualization via profiling feedback: http://hubicka.blogspot.com/2014/04/devirtualization-in-c-part-5-feedback.html http://hubicka.blogspot.com/2014/04/devirtualization-in-c-pa... As you suggest, it's a little misleading to talk about the runtime cost of a virtual or indirect function call in isolation. The most significant cost is often the resulting inability of the compiler to inline and perform further optimizations across the caller and callee.
- eloff 10y ago
  Nice, I had a feeling they did that, thanks for the link. I fully agree, missed optimization opportunity from not being able to inline is usually a bigger effect, because loops dominate the runtime and that's where those optimizations count.
exDM69 10y ago
Virtual function / function pointer calls can still have a big performance impact, especially if it could be inlined away. Compare C standard library qsort with C++ std::sort performance for sorting integers. The difference is huge in favor of std::sort. If you write your own qsort and put it in a header file so the indirect calls can be inlined, they should be equal.
jheriko 10y ago
i've seen virtuals completely removed and inlined by gcc when there is enough information for it to do that, and a simple enough use case... probably other compilers are similar.