the book was better

Here is a cute video of a benchmark I’ve been looking at in recent times. It’s nice because it not only shows the performance improvements, but also the themeing fixes that were applied. The benchmark shows glade starting up and loading a huge glade file with 4 different GTK versions. It starts with executing glade on the command line and ends with the app quitting when it’s done loading. The 4 comparisons are:

GTK 2 GTK 3.0.0
GTK 3.0.7 GTK git master

Some details about this for anyone who likes nitty-gritty details:

With 27s vs 37s GTK 2 is still faster than GTK 3′s master branch. Measurements indicate that this is mostly related to widgets not being optimized for height-for-width yet but being straight up ports of the GTK 2 versions. And we do at least twice as many size requests with the new GTK. We first query the width and then the height for the returned width. So we run the size computation code twice…

With 37s vs 53s the GTK 3 master branch is faster than 3.0.7 because I spent some time fine-tuning label size querying and Tristan spent time caching size requests so we don’t have to repeatedly do them.

With 53s vs 1:11 3.0.7 is a lot faster than 3.0.0 because we initially were very careful at invalidating style information when widgets changed. Unfortunately that caused the code to update the CSS styling information 6+ times when creating a widget. And that was very noticable. So I dived into the code and tuned it and we now only query the style information once. As it should be.

And the TL;DR version: GTK 3 is getting faster every day. But if there’s something where GTK 3 is way slower than GTK2, it might be something that we missed, so don’t hesitate to provide us with a way to test it.
We can make nice videos out of it!

13 comments ↓

#1 jeff on 03.30.11 at 23:32

Does this affect the speed of drawing menus in GTK3? (bug 640995)

#2 Sam Thursfield on 03.30.11 at 23:51

a nice way of presenting performance tests! in addition to the great performance improvements.

#3 Richard on 03.31.11 at 04:49

I’m glad we’re getting closer to GTK+ 2.x, but I already found GTK+ 2.x applications slow to build. Is the plan to on average reach parity or exceed GTK+ 2.x any time soon?

Appearance wise, it’s alarming the amount of space that gets wasted, how much screen real-estate is lost. Are the extraneous padding on the toolbar and the very-wide tabs properties of the theme used or are they inherent to GTK+?

#4 Richard on 03.31.11 at 04:53

Actually, can you give any advice on how to do fine-grained performance profiling for GTK+?

Perhaps I could propose a GNOME SoC project around speeding it further :) It would be nice to minimise the contribution of GTK+ to application start-up times.

#5 Mathias Hasselmann on 03.31.11 at 06:41

How do I play that video? Ubuntu 10.04.2 LTS has no clue of webm.

#6 Benjamin Otte on 03.31.11 at 06:45

@jeff: I commented in the bug.

@Richard: The extra padding is part of the theme and done on purpose. I’m sure the designers will be able to point you to lots of articles on why and how whitespace matters. See http://people.freedesktop.org/~company/stuff/glade-no-extra-space.webm for a quick demo of setting all borders and paddings to 0.
And no, there is no plans to make GTK 3 as fast or faster than GTK 2. What we usually do is we take stuff that is annoying us and try to make it faster. Sometimes successfully (as in this case), and sometimes not. But GTK is an understaffed (and due to GNOME 3.0 overworked) open source project, so there’s usually not ever any concrete plans, let alone for performance work.

My “fine-grained performance analysis” usually involves a self compiled GNOME stack, a good benchmark, looking for clues in sysprof and lots of code reading. I have no idea though how much familiarity with the existing GNOME/GTK code this approach requires, but I suspect quite a bit.
But then, my approach to performance is a bit unusual, because I’m usually looking at ways to delete code to make things faster, not the usual approach of writing more code (like adding caches, or short-circuiting common cases).

#7 Richard on 03.31.11 at 06:48

Thanks for the substantial reply and answering my questions. I value that expense of time :)

#8 Benjamin Otte on 03.31.11 at 07:10

@Matthias: You get a proper, recent distro. Fedora13+ plays it. All browsers released in the last 6 months play it inline (okay, all but IE and Safari). Even one Ubuntu release further would play it.

#9 BogdanB on 03.31.11 at 11:42

Right click on the video and select “View video” or “Save video as”. VLC or mplayer will do the rest.

#10 Ernst on 03.31.11 at 18:09

@Matthias: https://launchpad.net/~mozillateam/+archive/firefox-stable

#11 aa on 04.01.11 at 14:56

Why is the loading in gtk2 faster?

#12 Benjamin Otte on 04.01.11 at 14:58

@aa: lemme quote from the post directly:
“Measurements indicate that this is mostly related to widgets not being optimized for height-for-width yet but being straight up ports of the GTK 2 versions. And we do at least twice as many size requests with the new GTK. We first query the width and then the height for the returned width. So we run the size computation code twice… “

#13 Desktop summit 2011: GNOME The State of the Union | Fer's blog on 04.26.11 at 11:13

[...] propietary plugins becuase blogs.gnome.org does not allow me to use the tag (event if it allows others doing it). Also hosting the video on people.gnome.org does not set the proper mime type so it [...]