Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-12-22 03:26:37


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 and 7 times slower than Qt.

> 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? And BTW, what is the use case for temporary
blocking specific connection?

> 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 .

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

- Volodya





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