
Devirtualization in LLVM and Clang - jjuhl
http://blog.llvm.org/2017/03/devirtualization-in-llvm-and-clang.html
======
ec109685
Impressive undergraduate work: Undergraduate student at University of Warsaw,
currently working on C++ static analysis in IIIT.

------
nayuki
On the Java side of things, devirtualization in the JVM's JIT compiler is
discussed in articles like: [http://insightfullogic.com/2014/May/12/fast-and-
megamorphic-...](http://insightfullogic.com/2014/May/12/fast-and-megamorphic-
what-influences-method-invoca/) ; [https://shipilev.net/blog/2015/black-magic-
method-dispatch/](https://shipilev.net/blog/2015/black-magic-method-dispatch/)

------
gigatexal
Maybe we should take the stackoverflow approach and code up some examples to
show the virtual function performance tax?

~~~
twoodfin
The most significant cost of virtual functions is hard to demonstrate in
micro-benchmarks: It's the optimization opportunities lost because you can't
inline.

------
gok
I’m curious how helpful this is in practice. Often, if you’re going through
the pain of using C++, you probably care a lot about performance, so you also
try to make sure to minimize use of virtual calls.

~~~
xorblurb
A virtual call on a modern processor is typically not very costly. Too much
inlining, OTOH, can be (if it generates bloated code that trashes your cache)

~~~
Coding_Cat
The call itself is not very expensive, but the effect of having to jump
through vtables can prevent other optimizations in a way similar to calling a
function in a DLL.

Not a huge issue for business logic bits or if your virtual functions are
quite large, but using virtual functions for small often used calls such as
specific getters or some mathematical function can cause a big performance
hit.

~~~
exDM69
Exactly. The cost is not the overhead from the actual call - it's the fact
that it inhibits other optimizations. The same applies to normal function
calls when link time optimization is disabled.

This only becomes relevant in hot loops, but inlining can give big wins when
combined with other optimizations.

~~~
xorblurb
I've seen some speculative inlining happening even without LTO (so obviously,
in the same TU) with GCC.

~~~
exDM69
Absolutely. Seems like modern compilers inline everything they possibly can,
regardless whether you mark your functions inline or not.

