Re: Fast handling of class-closure-only signals



>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]