Douglas Gregor wrote:
On Jun 18, 2005, at 9:43 AM, Christophe Prud'homme wrote:
Am I using boost::signals the wrong way? has boost::signals some added features that reduce its performance ?
The latter. The "slot groups" feature really slows Signals down.
As I understand it, you were going to remove it. Is that still in the plans ? I like the "slot groups" feature as it enables one to order signal handlers if necessary. This is sometimes both necessary and easy to do with slot groups when designing code using signals where one wants to guarantee that internal handlers be called before any user-defined handlers. But since it is slowing down Signals significantly, I think it should either remain run-time optional in some way where its non-usage would not slow down Signals, or removed. In this scenario, which I do not know it is possible for you to do, only those who use the slot mechanism would pay the higher price in slower calling of signal handlers. I do not know the Signals code but, as a suggestion, how about the ability to pass a bool to the signal constructor itself, defaulting to 'false', which determines whether or not slot groups are supported. If slot groups are not supported for a signal, then if a slot group is passed to a connect call the group is ignored and the slots are handled strictly with the FIFO. At the cost of some changes in code design would that not essentially save time by not having to cycle through the slot groups in order to call slots when the signal is triggered ? FIFO satisfies most people's needs and despite the fact that I had previously suggested a much more flexible usage in the past which you had largely adopted for signals, my opinion is that it is very important that signal handling speed compare reasonably to other systems, especially as signals may be used heavily for front-end GUI programming.