Re: [boost] [signal] performance

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-12-22 18:56:22

Douglas Gregor wrote:
> On Dec 22, 2005, at 3:26 AM, Vladimir Prus wrote:
> 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.

I do not know if this is doable, or even if you want to do it or 
consider it too much work, but I had suggested something like this a 
while back: a signal could be created, on an individual signal basis, 
with a parameter which says that it does not support named slots, and 
that this knowledge should allow you to use a much faster iterator to do 
signal processing once the signal is triggered or manipulated. Another 
possibility, along the same lines is what you have written just above: 
if no named slots have been added for a signal, which you can easily 
keep track of with an internal bool per signal, the internal code should 
theoretically be able to use simpler algorithms and data structures and 
thus speed up signal processing. In either case, those who use signals 
with named slots would have no reason to complain of slower signal 
processing, since it has already been determined that this slows down 
signals to a large extent and they would be told about it in the doc, 
while those who do not use named slots would benefit from faster processing.

No, I am not volunteering to implement this in your excellent code, nor 
do I pretend to understand the internals of signal, although I have 
looked at it occasionally, but just suggesting a possibility along the 
lines of "what you pay for you get". I realize this greater flexibility 
would come at the price of greater internal complexity and more 
difficult maintainability if it could be done, and that is a headache 
you may not want to pursue.