Re: [boost] [signal] performance

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-22 15:13:38

On Thu, 22 Dec 2005 11:26:37 +0300
Vladimir Prus <ghost_at_[hidden]> wrote:

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

To add (again), I think it is fair to compare boost::signal<> to
boost::function<> because it gives you an idea of the extra cost.  I
have seen the arguments about the cost of extra functionality.  However,
if you are not using the extra functionality, then you should not have
to pay for it.  However, the Boost.Signals design/implementation
requires the user to pay a performance penalty for features that MIGHT
be used.  This has always been my single most problem with the library.

I should be able to instantiate a signal that gives me the level of
functionality I desire.  However, the current library mandates that
simple users pay for complex and expensive features that are not used.