>you are fighting a strawman. The decision to use virtuals or not has to be taken in the context of all the benfits, and inlining is a prominent one among them.

>you are fighting a strawman. The decision to use virtuals or not has to be taken in the context of all the benfits, and inlining is a prominent one among them. Agree that the decision to use vtable must consider all the disadvantages including loss of inlining. The previous poster also already mentioned that as well. My question about comparison was not about the decision of yes-or-no to virtual calls. It was about understanding the 15% penalty of vtable calls compared to normal non-inlined calls. If someone had a snippet of code showing that large of a penalty on a modern cpu, I thought it would be interesting to disassemble the compiler's output and study it. When the previous poster (coherentpony) was complaining about 15%, I thought he was specifically talking about normal function calls because the poster he was responding to was restricting the word "negligible" to normal function calls. My questions were a continuation of that narrow and focused benchmark. Yes, I think most people understand vtables are not "free". They have a cost. When Alexander Stepanov introduced the STL in the 1990s, one of the factors leading to fast adoption was that it used templates with extensive inlining and the performance blew away the previous attempts of algorithms+containers designed with inheritance & vtables. Heck, a C++ std::sort() could be even faster than C qsort(). Hope that clears up what my curiosity was about.