Re: Speed impact of virtual inheritance

[Frans Englich <frans dot englich at telia dot com>]

On Monday 10 October 2005 18:53, Mark Mitchell wrote:
> Frans Englich wrote:
> > Hello all,
> >
> > In a large project I'm participating in, a design dilemma have arrived.
> > Adding virtual inheritance would solve it beautifully on the source code
> > level, but a potential drawback is the speed penalty it brings.
> > Measurement is always the way of approaching performance questions, but
> > since that sometimes can be tricky, I thought of starting with getting a
> > theoretical understanding of virtual inheritance.
>
> In GCC, the performance cost is very slight.
>
> In constrast to older implementations (in GCC and other compilers),
> there is very little cost in terms of bytes per object for use virtual
> inheritance.  (The only cost is that the most derived class must have a
> virtual table pointer; if the hierarchy has at least one virtual
> function, then there is no additional cost relative to that.)  There is
> an increase in the size of the virtual table (of which there is one
> instance per class, not one instance per object) proportionate to the
> number of virtual base classes.
>
> The execution-time cost is two memory references required when casting
> to a virtual base class (as opposed to zero in the case of a cast to a
> non-vritual base class).  Calling a virtual function will require a few
> additional instructions if virtual bases are involved; however, a
> function call is itself expensive, and virtual function calls typically
> cause i-cache misses, so the virtual-base part of the cost is quite small.

Followup question: what is the increased cost of calling a non-virtual, 
inlined function('inline' keyword) on a virtual base? The Shared::ref() 
function given in the initial mail could be used as example, it uses a member 
on the object. I could reason about possible answers, but I think it would 
make little good.

> There may be negative secondary optimization effects if the optimizers
> are no longer able to reason effectively about your code.
>
> My advice would be to use virtual bases in your class hierarchy where
> that seems attractive from a design point of view, but to avoid virtual
> function calls to small functions in performance critical loops, whether
> or not your hierarchy uses virtual bases.

Yes, sounds sensible to me too. 

What makes me ask these questions, is that I have code which(according to my 
opinion) severely needs virtual inheritance(VI). The code VI would affect is 
not under my veto power, and the maintainers of that code have so far given 
as comment "VI is out of the question. Period," without giving a deeper 
motivation, except "performance."

The alternative solution proposed to my VI problem would require adding 
another memory management layer on top of the current(another smart ptr, and 
so forth). I, who am of the "Go for readability, flexibility, and afterwards 
optimize according to measurements"-school, find this alarming, and worries 
that the non-VI solution can be counterproductive, even in the area it tries 
to excel(due to code complexity, that optimizers have difficulty 
introspecting).

Jonathan's and your's replies, as well as the report Jonathan referenced, does 
in my opinion show a nuanced picture of VI. I don't think an engineer can 
with this information as background take a decision motivated with 
performance, without taking a very close look at the specific case.

I wonder -- and goes outside the scope of this mailing list -- what does on 
do, when code is about to be obfuscated in the name of performance, without 
substantial evidence for doing so? Is there a paper or something special I 
can do, in order to reduce "empty" performance arguments?[1]


Cheers,

		Frans

1.
I ask it, because I think it is somewhat a phenomena that programmers argue 
performance without having concrete evidence to back it up.