How many virtual functions before needing dispatch tables?

[The Stevemeister]

Hi, I have an entity class (from a rendering engine)
with about 100 functions now that are virtual. So far
no slowdowns, but since I've done alot of work with
OWL and MFC over the years, and I know that when the
virtual functions get too many, OWL and MFC result
to dispatch tables.

Question is, at what point do I say, "At what point
do I switch to dispatch tables?"

Thanks,

 

[Ivan Vecerina]

Hi, I have an entity class (from a rendering engine)
with about 100 functions now that are virtual. So far
no slowdowns, but since I've done alot of work with
OWL and MFC over the years, and I know that when the
virtual functions get too many, OWL and MFC result
to dispatch tables.

Question is, at what point do I say, "At what point
do I switch to dispatch tables?"

You shouldn't really worry about the number of virtual
functions alone - as long as each of the concrete
implementations of your base class implements/overrides
most of these functions.

The problem for MFC/OWL is that there are hundreds
of messages that need to be handled by a widget,
AND most of the many subclasses that exist only need
to implement/override a few of these messages.
The drawback of virtual tables then is that, even
if a subclass overrides a single virtual function,
it needs to have its own copy of a complete virtual
table with hundreds of (unchanged) entries. This is
what ends up being expensive.

Another issue with virtual tables is the fragile
base class problem: if a virtual function is added
or removed from the base class, all the subclasses
need to be recompiled (and their vtbls rebuilt).
This is only a real problem if, as OWL/MFC, you
distribute a library in binary form only, and others
need to subclass its contents.

Unless either of these problems is relevant to your
class, you will benefit from easier maintenance and
better execution speed by sticking with C++ virtual
functions.


I hope this helps,
Ivan

 

[David White]

Hi, I have an entity class (from a rendering engine)
with about 100 functions now that are virtual. So far
no slowdowns,

I wouldn't expect a slowdown no matter how many virtual functions you have,
for the same reason that I wouldn't expect the time to access a specific
element of an array to increase if you make the array larger. For most CPUs
a virtual function call is just a couple of indirect memory accesses at
constant offsets and then an indirect call.

but since I've done alot of work with
OWL and MFC over the years, and I know that when the
virtual functions get too many, OWL and MFC result
to dispatch tables.

That's not because the number of virtual functions would cause any slowing.
There are probably a number of reasons they chose such a system, but one is
that you don't know what messages need to be despatched until run-time,
since users can define their own messages, whereas virtual functions need to
be known at compile time.

DW

 

[The Stevemeister]

Oh I see... makes perfect sense now. Thanks alot
for the information guys.
Steve

 

[Mike Smith]

Hi, I have an entity class (from a rendering engine)
with about 100 functions now that are virtual. So far
no slowdowns, but since I've done alot of work with
OWL and MFC over the years, and I know that when the
virtual functions get too many, OWL and MFC result
to dispatch tables.

Question is, at what point do I say, "At what point
do I switch to dispatch tables?"

IIRC the use of dispatch tables is not due to the *number* of functions,
but rather they are used to provide the mapping between Windows messages
and virtual functions to handle those messages. Needless to say, there
are *lots* of Windows messages that a given GUI widget might need to
handle...