virtual functions vs speed

[Andrey Tarasevich]

...
I am guessing here, but in a worst case scenario this might imply
something like 20+ additional cpu cycles in comparison to non-virtual,
inlined code. Compare that to the cpu cycles your function causes, and
you can evaluate the tradeoff you are facing.
...

I'm sorry but that looks like a meaningless comparison to me. OP is
considering virtual functions, which immediately means that he really
_needs_ some form of late binding (run-time dispatch) for these
functions in his program. "Non-virtual inlined" functions simply won't
satisfy this requirement. There's absolutely no point to involve them
into comparison.

If you want to obtain a meaningless estimation of overhead introduced by
some particular implementation of virtual dispatch mechanism, you have
to compare it to other functionally equivalent (at least within the
context of the problem at hand) implementation of the dispatch.
"If-ladder", "switch-case", "function pointers (in non-shared vtables)"
are all examples of different run-time dispatchers that might
potentially outperform the traditional "shared vtable" approach. But in
many (if not most) cases it is simply not worth it.

 

[Andrey Tarasevich]

...
If you want to obtain a meaningless estimation of overhead introduced by

^^^^^^^^^^^
Oops. I meant to say "meaningful" here

 

[Arno Huetter]

I'm sorry but that looks like a meaningless comparison to me. OP is
considering virtual functions, which immediately means that he really
_needs_ some form of late binding (run-time dispatch) for these
functions in his program. "Non-virtual inlined" functions simply won't
satisfy this requirement. There's absolutely no point to involve them
into comparison.

The original poster asked:

How much is the slow down and is there a workaround?

And the first part of his question is exactly what I tried to answer -
the slowdown in comparison to non-virtual function calls. Plus I think
the tradeoff cost must be seen in context of the function's overall
runtime complexity. I cannot suggest an alternative implementation
that's faster - I guess there must be a reason there have been vtables
ever since ;-)

BTW managed environments like Java or .NET can do a better job on
that. The JIT can optimize the virtual call, in case it knows there is
no further subclass that overrides the method.

Kind regards,
Arno Huetter

 

[Peter Koch Larsen]

Andrey Tarasevich <[email protected]> wrote in message

BTW managed environments like Java or .NET can do a better job on
that. The JIT can optimize the virtual call, in case it knows there is
no further subclass that overrides the method.

So can a C++ compiler, even if I grant there should be fewer places where
that could happen (no "final"). It is not an optimisation that is likely to
give you anything, of course.

Kind regards,
Arno Huetter

/Peter

 

[Arno Huetter]

So can a C++ compiler, even if I grant there should be fewer places where
that could happen (no "final"). It is not an optimisation that is likely to
give you anything, of course.


/Peter

Peter,

but this can only be decided at runtime in most cases (due to
polymorphism), not at compiletime.

Kind regards,
Arno Huetter

 

[Markus Elfring]

I have the following trade off to make:

A base class with 2 virtual functions would be realy helpfull for the
problem I'm working on. Still though the functions that my program will use
a lot are the ones that are virtual and thus will slow down the
calculation, at least that is what what I have read on several places on the
internet. It makes sense the program has to work with some kind off lookup
table for the virtual functions to excatly know what function to call.

A lot of C++ implementations use a pointer to a table of those
functions. You should decide if you can afford the memory and
processing for this specific pointer.

Does your design expect that your special classes should behave like
value objects?
http://c2.com/cgi/wiki?ValueObject

This design decision was made for the Standard Template Library which
uses code generation instead of polymorphism for the containers
because of speed reasons.

How much is the slow down and is there a workaround?

I have been thinking about using function pointers but that seems as nasty
trick which will only create a lot development problems later on.

Your code will not be faster with your own function pointers than the
compiler's approach.
If you really need polymorphism, you must pay its "price".

Do you apply a pattern like the following example?
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html

Best regards,
Markus Elfring