Support #637
closedboost::signals2 instead of boost::signals
0%
Description
Currently used boost::signals seem to take too much memory.
Acording my tests, each boost::signal with one connected slot takes ~510 bytes of memory
most of my application memory is used by signals
boost::signal2 with one connected slot takes ~350 bytes of memory
In addition, boost::signals2 is thread-safe
Libsigc signals could be also used
sigc::signal with one connected slot takes ~100 bytes of memory
Libsigc signals provides interface same to that of boost::signals
Updated by Koen Deforche over 13 years ago
Hey,
I understand your gripes against boost::signal, but so far, it remains the best practical solution. Boost::Signals2 relies on boost::shared_ptr for automatic connection control, which is not feasible or desirable for Wt.
As to thread-safety, it doesn't make much sense to have thread-safe signal/slots in non-thread safe widgets.
Finally, Wt does not allocate signals which are not connected. So the memory usage for most signals is 0. And you could chose to use another signal library for connections between your own components, if this becomes critical for you. In any case, we would not switch to libsigc but rather upgrade to Boost::Signals2 which does not give you that much memory savings ?
Regards,
koen
Updated by Boris Nagaev over 13 years ago
Memory saving provided by boost::signals2 compared with boost::signals seems significant.
It would save about 30% of memory
Updated by Koen Deforche over 13 years ago
- Status changed from Feedback to Closed
Hey Starius,
30% for the signals themselves, I can believe that. But you need to compare to the memory used by widgets overall. Currently you only pay for signals that actually have connections --- if you find yourself in a situation where you need to create many connections to event signals, then usually you can optimize this to catching the event only in a base container and decode the signal target: that is even more efficient in terms of generated HTML/JavaScript, but it usually requires a custom JavaScript handler. I am still not convinced this is is a fair trade-off.
In any case, moving to boost::signals2 is simply not technically feasible so there is no choice.
Regards,
koen