| Thread Previous • Date Previous • Date Next • Thread Next |
al davis wrote:
On Wednesday 24 February 2010, Wayne Stambaugh wrote:Each level of derivation adds an additional index dereference to the vtable of the class it is derived from. If you don't derive from a base class then no dereferencing overhead is incurred. With modern processors it probably makes little difference in speed and certainly nothing compared to the speed increase (hopefully) of using a hardware accelerated drawing API.That is not what I recall ... As I remember, each vtable is complete, so any call is: (*(this->_vtable->function))(args); regardless of the depth.There is a link back for other reasons, but calling a virtual function does not trace back.I admit I have not looked at it in many years, but when I did this is what it did. In the early days of C++ and STL I questioned the efficiency cost, so I investigated some of what I thought were potential issues. Every time, I found that the actual implementation was sensible and efficient. Stroustrup has stated in public that run time efficiency was considered important, and that no sacrifice compared to C was acceptable.
Yep, seems accurate for single inheritance, which is what we are talking about.
If "this" is assumed to be registered, then I count two more memory reads for a virtual call than for calling a non-virtual C++ function:
1) *_vtable2) the offset into the vtable for "function" which is found in the code stream.
The final reading of the function from the vtable is not really "additional", when you consider that the non-virtual C++ call has to do a similar read of the function address from the code stream.
So this is how I get +2. If "this" is not registered, sometimes you will see a 3rd read, but you'd have that anyway in the non-virtual call also since this is passed as the first argument and so has to be read.
And it would take a lot of looping and a lot of calls for this to be detectable, but its cost is precisely the cost of 2 memory reads, not more, not less, IMO.
So I don't think C++ is having problems.... :)Virtual functions are good enough for polymorphism and sharing functionality between a screen and a printer. But if you were only going to need "compile time" alternative screen strategies (and no printer/pdf/svg support, i.e. no need for polymorphism), this could be done with a compile time typedef on alternative class names, and avoidance of virtual functions altogether.
To me it looks like the printer is what brings in the polymorphism need. The double function calls in wxwidgets is without sufficient merit IMO. It can save code space at the cost of yet another function call, but this is not what we want. Speed seems important to everyone.
Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
