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. 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. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
