Re: Fast handling of class-closure-only signals
- From: James Henstridge <james daa com au>
- To: Soeren Sandmann <sandmann daimi au dk>
- Cc: gtk-devel-list gnome org
- Subject: Re: Fast handling of class-closure-only signals
- Date: Thu, 28 Aug 2003 08:45:02 +0800
On 28/08/03 03:48, Soeren Sandmann wrote:
Recently, Tim applied a patch to gsignal.c that avoids emitting
signals that won't have any effect. Such signals are common during
TreeView validation, so people who have performance problems here may
want to upgrade to GLib CVS HEAD.
Anyway, I got an idea from reading his patch. You can view what the
noop patch does as:
- Is the class closure for this signal NULL?
- if yes, does anything else than the class closure need to run?
- if no, omit the emission.
So my idea is to export API that does the check in the second step. By
using that, gtk+ and other users of GObject can do
if (g_signal_check_class_closure_only (object, signal_id, detail))
FOO_GET_CLASS (object)->the_handler (...);
else
g_signal_emit (object, signal_id, detail);
ie. directly calling the virtual function if nothing else needs to be
done.
For signals that only rarely have handlers, like "expose" or
"size_allocate", but always a class closure, this is a big speed-up.
I am attaching two patches, one for glib and one for gtk+. The glib
patch exports the function g_signal_check_class_closure_only(), and
the gtk+ patch makes use of this call to check if the event, size
allocate, and the check_resize signals can be skipped.
With these patches applied I measured with Gnumeric and Nautilus how
often the signals were skipped by this during opaque resizing. The
results are that
for Gnumeric 96.9% of the checked signals were skipped
for Nautilus 94.6% of the checked signals were skipped
I also noted that the time spent inside g_signal_emit() (as measured
with SpeedProf) during resize of Gnumeric dropped to around 2%.
The main drawback is that for signals that actually *do* need to be
emitted rather than directly called, the "class_closure_only" code
will run twice. But as the numbers show, that is rare.
Will this code affect objects where g_signal_override_class_closure()
has been called? In this case, the class closure may be the only
callback for the signal, but it wouldn't be correct to short circuit to
the C function pointer.
James.
--
Email: james daa com au
WWW: http://www.daa.com.au/~james/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]