|
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