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.
, 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
An approach where the slot list is more list list<pair<function<...>, bool> the feature. It seems like a good application of pay-for-what-you-use. Regards, Dave