kicad-developers team mailing list archive
Mailing list archive
Re: Graphics Abstraction Layer (was Re: wxDC & wxGraphicsContext
Dick Hollenbeck <dick@...>
Fri, 26 Feb 2010 00:02:01 -0600
Thunderbird 188.8.131.52 (X11/20090817)
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
That is not what I recall ...
As I remember, each vtable is complete, so any call is:
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
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:
2) the offset into the vtable for "function" which is found in the code
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.