Re: [boost] [signal] performance

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-12-22 09:32:45

On Dec 22, 2005, at 3:26 AM, Vladimir Prus wrote:

> Doug Gregor wrote:
>
>> We have to be realistic about the features that have been omitted in
>> the simple, fast models against which Signals is being compared. For
>> instance, the example program under discussion ignores several  
>> factors:
>> 1) function<>s/function pointers never call more than one target, so
>> they have no internal iteration constructs. Any Signals  
>> implementation
>> must have these iteration constructs (so we need to at least compare
>> against a vector of function<>s or function pointers)
>
> Ok, let me try a comparison against vector of function pointers and  
> vectors
> of boost::function. Test case attached. And I have another test  
> cast, also
> attached, which tests signals performance in Qt.
>
> Results:
>     function pointer     0.1 sec
>     Boost::function:     0.31 sec
>     Boost::signals       9.5 sec
>     Qt                   1.3 sec
>
> Boost.Signals is 30 times slower then Boost.function and 95 times  
> slower
> than function

So it was 50 times slower than a single Boost.function, 30 times  
slower than a single Boost.function in a vector.

> and 7 times slower than Qt.

It's important for us to improve this.

>> 2) target function objects can modify the iteration sequence during
>> iteration. This results in additional iteration overhead that doesn't
>> show up in the simple models, e.g., because one can add or remove  
>> slots
>> while iterating through the list.
>
> What is the use case for that?

It's especially good for one-shot slots: connect the slot, then once  
it fires it disconnects itself. It also happens when slots cause one  
of the objects connected to them to essentially "delete this", as  
would happen if your slot involved destroying a window within a GUI.  
This happens surprisingly often.

> And BTW, what is the use case for temporary
> blocking specific connection?

It was a persistent user request followed by a patch from a user. I  
don't recall the use cases, but I expect it has something to do with  
temporarily disabling calls into a component while that component is  
reinitializing itself.

>> I'm not saying that it isn't useful to compare the performance of
>> Signals against simpler models, but we need to compare apples to  
>> apples
>> if the comparison is going to help us improve.
>
> If by "apples to apples" you mean comparison to other signal  
> implementation,
> then:
> 1. See comparison with Qt above
> 2. I don't think it's right anyway. Boost::signals has extra features
> compares to Boost::function and it's fair to estimate the price those
> features have compared to Boost::function       .

Sure, but we have to know what features we're measuring. There's no  
signal implementation that consists of a single function pointer, so  
while it does provide a lower bound on the call time for a signal,  
that bound doesn't tell us anything. vector<function<> > is a  
reasonable baseline: the we add features such as connect/disconnect  
stability during invocation, slot blocking/unblocking, and named  
slots and see where that gets us. My guess? The combination of named  
slots and my attempts to avoid code bloat are killing signals  
invocation performance.

> Still, what do you think about some simplified boost::signal (maybe  
> a base
> class, or a #ifdefed) that will have better performance?

For I long time I've wanted to have a signal that doesn't permit  
named slots, so that we can replace the horrendous map<name,  
list<slot> > data structure in named_slot_map into a simple  
list<slot>. It even fits into the interface well: we would just add a  
partial specialization of signal<> like the following that uses the  
simple, faster list<slot>-type interface.

   template<typename Signature, typename Combiner,  typename  
GroupCompare, typename SlotFunction>
       class signal<Signature, Combiner, void, GroupCompare,  
SlotFunction>;

It may also be possible to have a common core of list<slot> and when  
Group != void have an auxiliary map from slot group names to  
iterators into the list. This tends to make disconnection rather  
tricky, however.

        Doug