-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 24 July 2009, Sajjan Kalle wrote:
What's surprising here is the long running time of the fragmented signal2 variant, which makes me belive there's a bug somewhere in it. Instead of connecting 100000 slots and disconnect 90000 randomly I connected 1000000 and disconnected 990000, the fragmented signal2 performance on invocation then jumps up to about 92 seconds for calling a signal with 10000 slots.
That's due to the way signals2 cleans up disconnected to its slot list (incrementally during connection and invocation). It only does a full cleanup when it has to do a deep copy of the slot list due to concurrent access. If you run the signals2 fragmented block 10 times in a row, the run time will decrease as the disconnected slots are removed. However, I should be able improve the situation by adding a bit of code to invocation so it checks for an excessive number of disconnected slots and forces a full cleanup if needed.
I think a lot of the disparities between signal and the vector variant actually is due to the underlying container used, a std::map will simply never beat the vector, and in fact signal will most likely perform considerably worse when slots go further and further apart and paging kicks in.
You should add a fragmented test using plain iteration over a std::list to
your benchmark. Also, you could try using a dummy_mutex for the signals2
signals, like:
namespace bs2 = boost::signals2;
using bs2::keywords;
bs2::signal_type