Hi,

 

I see that there's already been some discussion concerning the performance of the signals library, it's fairly old though so I hope nobody minds me brining it up in a new thread.

 

We use signals fairly extensively and have seen it coming in fairly high in our profiling sessions. I did a search on the mailing list and found a discussion from 2005 on the performance of the library, results at that time showed a vector with boost::function being about 100 times faster than boost::signals. Our tests shows that this still very much holds true. I suspect there difference is considerably worse on in order RISC processors. I think it would be nice if either the manual states that performance isn't one of the design goals of boost::signals, or that the interface allows the application programmer greater controll over implementation details which affects performance.

 

I saw in one discussion going ( although once again, an old one ) that boost::signals use list as the container of slots instead of for example vector. This is understandable for the general case since otherwise connecting / disconnecting slots would be very expensive on large collections. However one use case which I'd think is very very frequent ( which resembles ours ), is to have fairly few slots connected and a somewhat constant collection, in this case one would rather have the expensive connection management and instead have the better cache locality and invocation performance.

 

Blocking / unblocking slots is another feature which while useful for a lot of people perhaps should be optional. I don't know exactly how blocking / unblocking slots are implemented, but perhaps simply an added iterator which doesn't respect the blocked status could be easily added and a matching slot invocation function.