Re: [sigc] [performance] slot_base::empty

[Martin Schulze <martin-ml hippogriff de>]

Obviously my guess was not that far off. Neal submitted bug #167714,  
where the discussion continues:

http://bugzilla.gnome.org/show_bug.cgi?id=167714

Regards,

 Martin


Am 20.02.2005 18:50:00 schrieb(en) Martin Schulze:
> Hi!
>
> This behaviour is indeed not what I would expect. slot_base::empty()
> is
> an inline function that simply checks up to two pointers for 0:
>
> inline bool empty() const    { return (!rep_ || !rep_->call_); }
>
> So, if your app spends half of its time in slot_base::empty() it must
>
> be called millions of times!
>
> From what you write below, the calls to slot_base::empty() seem to
> come
> from signal_impl::sweep() which gets executed when slots are (auto-)
> disconnected or destroyed during signal emission. signal_impl::sweep 
> ()
>
> iterates through the signal's slotlist to remove slots that have been
>
> disconnected (so it's O(N)).
>
> My only explanation for the experienced behaviour is that you have a
>
> signal with _lots_ of slots connected and that you repeatedly emit  
> the
>
> signal and connect/disconnect slots during signal emission.
> Without further information about your code, however, it's hard to
> give
> some advice how to improve the situation.
>
> Maybe it's also possible to optimize signal_impl::sweep(). The
> difficulty is that the signal's slot list should not be changed  
> during
>
> signal emission. Otherwise things either get to complicated or the
> performance of signal::emit() suffers.
>
> Regards,
>
>   Martin
>
>
> Am 16.02.2005 17:23:14 schrieb(en) Neal E. Coombes:
> > I've converted our system from using an old fashioned observer
> > pattern
> > to using signals.  For the most part everything performs well, but
> > there
> > is one feature that seems to take minutes instead of seconds now.
> >
> > I compiled my app for profiling and ran it for 22 minutes
> repeatedly
> > exercising this feature.  At the top of my gprof output is
> > slot_base::empty taking 49.3% of my applications run time (being
> > called
> > 400 million times).
> >
> > I optimized the app and repeated the above.  In this version at the
> > top
> > of my gprof output is signal_impl::sweep taking 50.46% of my
> > application
> > run time (being called 30 million times).
> >
> > My question:  What kinds of improper use of sigc could be causing
> > this
> > (so I might remove any such cases)?  On the other hand is there
> > anything
> > I might be able to do in sigc to reduce the number of times sweep
> > calls
> > empty?  or perhaps reduce the number of times sweep is called all
> > together?
> >
> > Any and all insights much appreciated.
> >
> > Thanks,
> > Neal
> >
> > _______________________________________________
> > libsigc-list mailing list
> > libsigc-list gnome org
> > http://mail.gnome.org/mailman/listinfo/libsigc-list
> >
>
>
> _______________________________________________
> libsigc-list mailing list
> libsigc-list gnome org
> http://mail.gnome.org/mailman/listinfo/libsigc-list