Signals is much slower than vector<function<...> > because it has to do a lot more work than vector<function<...> >. Much of the problem comes from the fact that one can disconnect slots from a signal while that signal is invoking slots. A comparison against something like list<pair<function<...>, bool> >, where the bool tells us if we should skip the slot or not, would give us a much better bound on the performance that could be achieved by Signals.
That said, named_slot_map::iterator is horrible for performance. It was built that way to decrease the object-file size for programs using Signals, named slots are just plain expensive. I think we can build a data structure that allows the implementation of the slot list to be similar to list<pair<function<...>, bool> >, with the mappings from named slots to position in the list stored in a separate data structure... but nobody has implemented this yet. My attempts to kill named slots outright, thus improving the performance of Signals, have met much resistance.
An approach where the slot list is more list list<pair<function<...>, bool>
, seems like a good step in the right direction. I appreciate the overhead needed in providing clean disconnect semantics during signal callbacks... I'd just like to see the named_slots overhead only 'hit' when actually using the feature. It seems like a good application of pay-for-what-you-use.
Regards, Dave