Re: Benchmark for short-circuiting of event signals

[Tim Janik <timj gtk org>]

On 20 Jun 2004, Soeren Sandmann wrote:

> A few weeks back I promised Tim that I would come up with more
> credible numbers for
>
>         http://bugzilla.gnome.org/show_bug.cgi?id=121027
>
> which was previously discussed here
>
>         http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00049.html

with a thread on API issues in:

	http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00159.html

that, as well as this thread should probably be added to #121027.

> So here is a benchmark. The benchmark contains an 'application'
> loosely modelled after Gnumeric. with lots of widgets in it. One of
> the widgets is a GtkHPaned, and the benchmark changes the position of
> the handle 2000 times causing lots of resizing and redrawing.

interesting, but still doesn't quite convince me to make changes though.
that is, my initial objections about timing (since your test case is
somewhat artifical, regarding whether users benefit noticably in real
world scenarios) still stand, and i wouldn't be surprised if major
bugs popup further down the line (that's in user code once the patch
was released) due to things like ref/unref missing around the function
pointer calls.

i still don't want to fully forgo the possible speed ups you point out
though. that is, i'd really like to see an analysis where the major
performance drawbacks in your scenario are with g_signal_emit() and
figure possible optimizations of that. so:

> * Try to do the speedup entirely within g_signal_emit()
>
>         I think it might be possible to skip both marshalling and
>         argument collection by using a platform specific hack to
>         convert a vararg list to a regular function call in the case
>         where we can determine that it will work.
>
>         I am not totally sure this will work, though.

might be something worth investigating. here, we should at least
be able to still ensure argument protection through ref-counts.

>
> Søren
>

---
ciaoTJ