Re: Some initial thoughts about 2.4

[Soeren Sandmann <sandmann daimi au dk>]

Owen Taylor <otaylor redhat com> writes:

> But "Make GTK+ faster" shouldn't be on the 2.4 feature list because
> it doesn't actually indicate any particular action. There are
> various performance related improvements that can be done that
> I know of.
>  
>  - GObject could be made 20-30% faster by careful code optimization

I have made some changes to memprof that collects information about
the tree of descendants of function, factoring out recursions. With
these changes, memprof --profile=cycles show that around 30% of the
time spent in gdk_window_process_updates() is signal emission
overhead. 

I haven't looked at the signal code, but maybe a "fast path" for the
common case where there is only one handler could be created?

> These are things that I've noted from spending weeks studying profiles
> of GTK+ and are generally reasonably major projects. The stuff that
> was easy to do and produced big improvements has been done.
> 
> I'd expect the overall improvement from implementing the above to 
> be order 10% ... I don't think it would be possible to make GTK+ 
> 50% faster without major feature removal. (Please prove me wrong ...) 

Well, during opaque resizing of Gnumeric, we spend 80% of the time
inside gdk_window_process_updates(). What this function does is that
it traverses the tree of invalid widgets and calls their expose
method. I think it will be a major speed-up if we could reduce the
amount of invalidation going on, by using the !REDRAW_ON_ALLOCATE flag
much more than we do currently.

This is also useful for NO_WINDOW widgets provided that they don't get
invalidated by their parents so generally containers should be careful
not to invalidate areas they won't draw on.

For Gnumeric, just making GtkWindow and GtkToolbar !REDRAW_ON_ALLOCATE
would increase the framerate significantly because all the pixbufs on
the toolbar wouldn't get redrawn on every mouse event.


Søren