Re: kde people is saying gtk is slow...

[Tim Janik <timj gtk org>]

On Thu, 24 Aug 2000, Karl Nelson wrote:

> >[...] This is of course

> signal case.  Gtk+ would be slower at emitting if you get sufficiently
> large numbers of signals connected to a widget, because gtk+ uses
> only one signal list which is an O(n) where n is the number of
> handles connected.  Assuming the gtk+ signal system to glib rewrite is
> good hopefully it will be O(log(m)) where m is the number of
> signals connected.   

the handler lookups will amount to something like a hashtable lookup +
O(log2(signal_ids_with_connections)), so yes, that's what the glib
implementation most probably will do.

> Gtk+ is slower than the fastest possible hardwired system partially 
> because of string usage but mostly because of global emission list
> manipulation.  But a global emission list is part of gtk+ design so
> you can't really fault it for speed.  Considering it is still 3 times 
> faster than C++/MOC in Qt, that really isn't a bad place to be.

in the GSignal code, i'm not keeping "emission lists" in the gtk manner.
it now merely amounts to a stack of recursive emissions per (instance,
signal_id) pair that doesn't need to be sequentially walked anymore.
i've yet to see hard numbers, that emission list walks are an actuall
performance penalty factor in current gtk code, but if that's the
case, you can expect speed improvements at least in this area.

> > I think the main reason why Gtk+ seems slow is that the drawing events aren't
> > handled correctly in the GDK layer or maybe with some Gtk+ themes (there
> > themes that seem to redraw at slow motion, sincerely). I'm willing to see the
> > new Gtk+ 2.0 fixing all this stuff. Owen has been working hard on this, so
> > it's just a matter of time.
> > Of course, it's clear to everyone (or at least should be this way), that we
> > want faster redrawing in Gtk+/Gnome (Mozilla included, the future
> > Nautilus,...) that we have now, because this is a thing that windows and kde
> > people aren't going to lose in their desktops...
> 
> No dispute there.  I was just reporting finding that owen had asked
> me to measure many moons ago and I had just been too lazy to document. :-)

we've had the general topic of gtk redrawings being "perceptually" slow
a couple of times. as has been pointed out before, the redrawings aren't
themselves slow, current gtk versions just redraw incrementally instead of
redraws appearing instantly from double buffered areas (which is what Qt
does, AFAIK). and yes, owen has adressed this in CVS HEAD, mainly by doing
double buffering by default, so future gtk versions will probably redraw
"perceptually" faster.

> 
> --Karl
> 

---
ciaoTJ