Re: [signals] Performance
Jody Hagins <jody-boost-011304 <at> atdesk.com>
2004-12-01 04:13:43 GMT
On Sun, 17 Oct 2004 19:36:39 -0500
"Aaron W. LaFramboise" <aaronrabiddog51 <at> aaronwl.com> wrote:
> On the other hand, as Alexandrescu in _Modern C++ Design_ quotes Len
> Lattanzi, "Belated pessimization is the leaf of no good."
> Alexandrescu goes on to write, "A pessimization of one order of
> magnitude in the runtime of a core object like a functor, a smart
> pointer, or a string can easily make the difference between success
> and failure for a whole project" (Ch. 4, p. 77). Library writers
> often do not have the same liberty as application writers to go back
> later, after profiling, and fix their slow code.
Right. My application is entirely event drive, with boost:signal()
dispatching every event. The application will be processing thousands
of messages per second, each one causing at least one signal()
> Preliminary analysis suggests that the performance efficiency of the
> demultiplexor when using this dispatcher is "bad." While I can not
> yet offer meaningful numbers, it seems that there is something quite
> slow happening under the covers in the Signals library. I have not
> examined the implementation of the Signals library at all, however.
> The extent of this problem, and whether it is easily fixable, remains
> to be seen.
I have not done much examination either, but to satisfy my curiosity, I
hacked together a "lite" implementation of the signals interface that
provides *minimum* functionality. Same interface as boost::signal<>,
w.r.t. connect(), disconnect() and operator() (i.e, dispatching a
signal). Also, allows connect/disconnect/replace inside a slot handler.