Conclusion: devirtualization optimization is so fragile, so that it's better to avoid using virtual calls in performance-critical code to be sure, that no virtual call happens.
It seems that for devirtualization GCC has a warning option -Wsuggest-final-types which is supposed to tell when devirtualization fails in link-time optimization. Not sure how reliable that is, or whether it will produce gobs of unhelpful warnings. Maybe it could be combined with some kind of hint that we want this particular call to be devirtualized, and don't care about calls without the hint.
That advice is often given, but I think few C++ programmers follow that to the letter, because you often know beforehand where your performance bottleneck is, and using some simple heuristics upfront may mean you won’t have to spend time benchmarking and refactoring later.
> If you're always going to the same place, the branch predictor can quickly figure that out even if the compiler can't.
But if the compiler knows which function is called, it can choose to inline it, can’t it? For short functions such as getters and setters, the difference can be huge. “call, move, return” instead of “move” is (ballpark) a factor of three, even ignoring cache pressure. The compiler may even choose not to construct a class instance at all, and keep its state in registers.
To be fair, in C++ that has been the ruling rule of thumb for since ever.
In such cases I prefer using std::variant instead of inheritance, but this works only if all possible types are known ahead of time.
A vector of variants still wouldn't be optimal. Better to use something like
https://www.boost.org/doc/libs/latest/doc/html/poly_collecti...
Transpose.