From: Edward Diener (eddielee_at_[hidden])
Date: 2005-06-18 12:15:21
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk