[Boost-users] [Signals] Another performance discussion

Subject: [Boost-users] [Signals] Another performance discussion
From: Sajjan Kalle (sairony_at_[hidden])
Date: 2009-07-22 10:23:13

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.