Some performance notes

[Owen Taylor <otaylor redhat com>]

Here's some notes about current performance. The benchmarking 
I did to get these conclusions was a combination of:

 - control-c profiling of opaque resizing (run under gdb,
   other window 'sleep 5 && killall -TRAP lt-testgtk, see
   where you are.)

 - Running Hans's testgtk benchmark with some different 
   compilation options.

 - Other debugging printf tets - for instance, printing out the
   results of timing each call to gtk_container_idle_sizer()

So, without including hard data (I don't have much), here are
my observations:

 * The GTK_IS_FOO() and GTK_FOO() debugging checks are hitting
   us pretty hard right now. The overhead of this is somewhere
   around 30%, which is a lot more than than it was in 
   GTK+-1.2.
  
   Aside from g_object_ref()/unref(), this overhead seems
   to be pretty distributed, with a good fraction (in drawing
   heavy tests) being in GDK.

 * With debugging turned off, the bulk of time was spent in
   the signal emission code and its GValue handling (40-50%)
 
 * ~10% of the non-debug time was spent copying GdkEvent structures.
   This is easily fixed by adding G_SIGNAL_STATIC_SCOPE to
   the GdkEvent signals. (this was part of the signal overhead
   mentioned above)

 * When opaque-resizing, another ~10 percent of non-debug time
   was spent maintaining invalid regions. This is probably quite 
   optimizable - some extra region copies are made, and it looks like 
   that adding a "completely invalid" flag to GdkWindow might allow bypassing
   a bunch of computations, since it seems like windows were
   getting invalidated repeatedly.

 * The overhead of double buffering is a rather hard to measure exactly 
   since it is spread between the client and the server. Things
   seemed to be 20-30% faster with double-buffering turned off.
   (But looked a lot worse.)

   A lot of creation and destruction of graphics contexts and 
   setting of clip rectangles could be avoided. This probably
   would cut down the client side overhead to very little. 

 * Most of the other time spent looked pretty spread out - though
   once we tackle the obvious stuff, more bottlenecks may
   be apparent.

Generally, on my tests on a 400mhz celeron I felt fairly good about
the overall performance with debugging off. Opaque resizing was a
little more sluggish than I would like, but other operations seemed
pretty snappy, and it would definitely have been useable on a slower
machine.

I would like to get the overhead of debugging down to the point where
we can ship with --enable-debug=minimum as we did for GTK+-1.2, but if
necessary we can go with --disable-debug for production builds and
just encourage developers to use --enable-debug versions.

If we can cut down the signal overhead some, and do a bit of work at
the top of the remaining profile, I think we'll do nicely.

Regards,
                                        Owen