Re: Fast handling of class-closure-only signals
- From: Owen Taylor <otaylor redhat com>
- To: Soeren Sandmann <sandmann daimi au dk>
- Cc: gtk-devel-list gnome org
- Subject: Re: Fast handling of class-closure-only signals
- Date: Fri, 12 Sep 2003 11:36:57 -0400
>From an API point of view:
if (g_signal_check_class_closure_only (widget, widget_signals[SIZE_ALLOCATE], 0))
{
GtkWidgetClass *class = GTK_WIDGET_GET_CLASS (widget);
if (class->size_allocate)
class->size_allocate (widget, &real_allocation);
}
else
g_signal_emit (widget, widget_signals[SIZE_ALLOCATE], 0, &real_allocation);
is horrid. We can certainly do somewhat better -
if (!g_signal_emit_slow (widget, widget_signals[SIZE_ALLOCATE], 0, &real_allocation))
{
GtkWidgetClass *class = GTK_WIDGET_GET_CLASS (widget);
if (class->size_allocate)
class->size_allocate (widget, &real_allocation);
}
Which, if you use the knowledge that GtkWidget has a default size_allocate
handler (you are never allowed to override a non-NULL default handler with
a NULL handler), isn't that bad:
if (!g_signal_emit_slow (widget, widget_signals[SIZE_ALLOCATE], 0, &real_allocation))
GTK_WIDGET_GET_CLASS (widget)->size_allocate (widget, &real_allocation);
Or more generically, we could make "g_signal_emit_slow()" check the class
closure pointer and only return TRUE if you need to call it.
The question is - can we make g_signal_emit() nearly as fast? Not completely
clear. What are the issues:
- Argument collection takes significant time. This could perhaps be
significantly sped up by hard-coding known fundemental types.
- There is quite a bit of "safeness" in the signal system that the above
bypasses. Obvious thing is that widget isn't ref'ed.
- Marshaling takes some time.
Do we have a profile of a micro-benchmark that just does class-closure
only signal emissions, to see where the time is going?
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]