Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-09-18 16:28:04


Hi Doug,

Douglas Gregor wrote:
> On Mon, 2007-09-17 at 21:23 +0200, Tobias Schwinger wrote:
>> I once hacked a quick benchmark to compare dispatch times of
>> Bind&Function (1.34 versions) vs. FastDelegate.
>>
>> With an inlineable replacement for 'boost::mem_fn' (accepting the member
>> function pointer as a non-type template argument)
>>
>> http://tinyurl.com/37tkap
>>
>> FastDelegate turned out to be (not quite) twice as fast as Function&Bind
>> with MSVC, which isn't that much IMO held against the lost flexibility,
>> such as not being able to use arbitrary function objects and only
>> binding 'this'.

Well, I have to correct myself. It's been a while since I last looked at
it and it seems to have improved (as it does handle function objects, by
now).

> FastDelegate will always have faster invocation, because it optimizes
> for a very narrow set of cases.

True. It seems the narrow set has become a bit wider, though.

However, Boost.Function in itself is not looking that bad, performance-wise.

Please note, however, that the great performance is achieved by
restricting ourselves to member function pointers known at compile time
(and a compiler that can exploit this information).
It's the invocation routine for member pointers emitted by the compiler
that makes up most of the difference.

It might be possible to modify Bind to implement the variants for the
"FastDelegate mess" and some introspection for Function to "invokerize"
the correct variant [for the protocol: this sentence assumes familiarity
with implementation details of Boost.Function].

> The invocation performance of Boost.Function won't have changed much
> from 1.33.x to 1.34.x. It's the copy performance that drastically
> improved. That part of the benchmark should be re-run with Boost 1.34.x.

FWIW, I'm fine just believing that calling operator new is slower than
not calling it ;-).

Regards,
Tobias


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk