[function] virtual function bloat
Hi, I'm writing documentation for my interface library comparing the performance of interfaces vs. base classes with virtual functions. I was going cite a reduction in code bloat caused by virtual functions, with a link to the Boost.Function docs. But when I read the function docs again I was surprised: I had thought the bloat was caused by duplicate vtables being placed in different translation units; I see instead that the bloat cited is attributes to auxiliary type-classification functions. In the interface library I construct artificial vtables containing pointers to free functions, but each table has a slot reserved for a function which allows the type of the bound object to be partially recovered. Could this extra function mean that any improvement in code size achieved by eliminating virtual functions has been canceled out? I realize I haven't given much info about my library; I can supply more if necessary. Any insight would be greatly appreciated. Jonathan
On Monday 24 January 2005 07:20 pm, Jonathan Turkanis wrote:
I'm writing documentation for my interface library comparing the performance of interfaces vs. base classes with virtual functions. I was going cite a reduction in code bloat caused by virtual functions, with a link to the Boost.Function docs. But when I read the function docs again I was surprised: I had thought the bloat was caused by duplicate vtables being placed in different translation units;
That could contribute some, but...
I see instead that the bloat cited is attributes to auxiliary type-classification functions.
That's what we found. The use of virtual functions makes a class polymorphic, which requires (among other things) a virtual destructor, support for dynamic_cast, and support for dynamic typeid: these things together were causing a lot of code bloat.
In the interface library I construct artificial vtables containing pointers to free functions, but each table has a slot reserved for a function which allows the type of the bound object to be partially recovered. Could this extra function mean that any improvement in code size achieved by eliminating virtual functions has been canceled out?
You'll probably still get some benefit. Function tries to save on space by smashing about 7 different functions into 2 functions, so that less code is generated. You might want to measure the effect in some typical use cases first: using virtual functions is a heck of a lot nicer than dealing with a library coded like Boost.Function, so you _really_ want to make sure it's worth the effort (it can always be optimized later). Doug
Douglas Gregor wrote:
In the interface library I construct artificial vtables containing pointers to free functions, but each table has a slot reserved for a function which allows the type of the bound object to be partially recovered. Could this extra function mean that any improvement in code size achieved by eliminating virtual functions has been canceled out?
You'll probably still get some benefit. Function tries to save on space by smashing about 7 different functions into 2 functions, so that less code is generated.
Yes, I was just examining the implementation yesterday. Currently, at the beginning of each function table, I have - an optional deletion function - a function which casts the stored void* to the static type of the object at the time of binding and then throws it as an exception - a function returning a type_info object I'm probably going to add a function that take a void function as an argument, invokes it, then tries to catch any exceptions it throws. These three or four functions could be combined into one as in Boost.Function, but I'll leave that for later.
You might want to measure the effect in some typical use cases first: using virtual functions is a heck of a lot nicer than dealing with a library coded like Boost.Function,
Tell me about it! :-)
so you _really_ want to make sure it's worth the effort (it can always be optimized later).
There were a number of reasons that virtual functions were not the best solution. Most importantly, I wanted full control of the ABI. Having already finished the implementation, I'm just trying to find as many retrospective justifications as I can ;-) Best, Jonathan
participants (2)
-
Douglas Gregor -
Jonathan Turkanis