Re: gsignal speed

[Tim Janik <timj gtk org>]

On 12 Dec 2000, Havoc Pennington wrote:

> 
> Hi,
> 
> Appended program is 12 times slower with GTK 2 than GTK 1.2, 4 times
> slower with --enable-threads=no --enable-debug=no for GLib. GTK 1.2
> has debug/threads enabled. Adding/removing the gtk_signal_connect()
> has no significant effect on speed ratios.

we have a bunch of expensive checks in place now.

> We can't have the checks slowing us down 3x, since we usually leave
> them on in the production version. Maybe we can add
> G_DISABLE_EXPENSIVE_CHECKS.

before we take such steps, we have to create a usage profile to really
figure where the time goes.
the signal and type code from 1.2 has been extensively profiled and
optimized back in the 1.0 series, 2.0 has complete reimplementations
and never went through speed optimizations, what do you expect?

besides that, your test is rather artificial, in overall performance
it's not pure signal emissions performance that hurts us, since they
are fairly spread over runtime.
things like object creation/destruction tend to give much better
perceivable performance improvements.
the gdk parts are vastly slower than in 1.2 (perception), we have
to do a bunch of profiling there as well.

> Of course, even the 4x slowdown with all checks turned off is
> suboptimal.

have you by any chance tried compiling with disabled checks?

the new type code eats its portion too, and i'm currently doing
lots of checks per-handler-parameter, we never did that before.
all in all, i have lots of ideas of how to make the signal code
more performant, those and additional optimizations based on
hard figures can give us major speed ups. it's too early to
work on those though, there're lots of other areas in gtk where
i want to see stabelization before we do performance nit-picking.

> 
> Havoc
> 

---
ciaoTJ