Re: Some performance notes

[Tim Janik <timj gtk org>]

On 6 Aug 2001, Owen Taylor wrote:

> 
> Soeren Sandmann <sandmann daimi au dk> writes:
> 
> > Owen Taylor <otaylor redhat com> writes:
> > 
> > > So, without including hard data (I don't have much), here are
> > > my observations:
> > 
> > I think it is important to also do some measurements with real
> > applications to see which parts of Gtk they spend their time in.
> > 
> > >  * With debugging turned off, the bulk of time was spent in
> > >    the signal emission code and its GValue handling (40-50%)
> > 
> > Speeding up signals may be a matter of caching.  I can easily imagine
> > time-critical code emitting the same signal over and over.  I don't
> > know if caching makes any sense in the code, though.
> 
> In general, the signal emissions aren't retrieving information
> so I don't think caching is relevent. An exception to this is
> size-request. There might be some noticeable improvements
> for resizing if we:
> 
>  - Add a private flag for the widget "has requisition"
>  - Clear the flag initially and on queue-resize
>  - Set the flag after ::size-request.
>  - Use widget->requisiiton instead of emitting ::size-request
>    when the flag is set.

i doubt there'd be much benefit from this, since
1) most size-request implementations don't do a whole lot of shuffling
2) queue_resize would have to flag a sub-tree recursively since containers
   can queue resizes on a) their children b) themselves, c) occasionaly
   their parents in order to get the whole sub-tree re-requested
3) upwards-propagation of newly queued resizes for GTK_RESIZE_PARENT
   would cause most of the tree to be flagged anyways
4) we already coalesce resizes through a high-prioritized idle handler

> Another emit-less-signals approach is that we could avoid
> calling size-allocate if:
> 
>  a) queue_resize wasn't called on the widget itself
>  b) The allocation of the widget is the same as before 
>     
> Unfortunately, widgets have been known to store things other than
> their actual allocation in widget->allocation, which poses a problem
> for this.

i'd also expect subtle bugs from this.

> A lot of signals are also emitted at setup time (parent-set,
> heirarchy-changed, notify, show, map, etc), and setup time is
> something we also really need to work on - perhaps more than
> resizing. So, I don't think "emit less signals" is the full solution.

jup, i think the very first thing to do is speeding up signal
emission in general.

> > and a non-negligible amount on gtk_widget_style_get()).  
> 
> Yes, I saw this too. I think g_param_spec_pool_lookup() may
> need a good kick in the rear. 

for the common code path (that is people looking up parameters
with their canonical name) g_param_spec_pool_lookup() does one
hash table lookup (pname, otype) for an object parameter and
if not found continues with the object's parent type.
i'd like to know how you intend to speed that up.

> Advantages queueing has over compression are:
> 
>  - safe, better compression - you frequently get the situation
>    where you can't safely compress event type A across event
>    (You can't compress exposes across configures safely), but
>    queueing allows you to compress as much as makes sense.
> 
>  - less complicated code
> 
>  - reading forward in the event queue in X is really inefficent.

plus, you coalesce resizes caused by configure events with other
resizing sources, e.g. widget layout alterations.

> Expose compression in GTK+-1.2 is O(n^2) in the size of the queue
> and has to avoid a lot of meaningful compression because of 
> safety issues with intervening events.
> 
> > (At some point I introduced > a low priority idle loop to take care of
> > calls to g_object_unref - this really made a difference).
> 
> I assume you mean by this "to take care of freeing objects"  -
> if g_object_unref() is slower than adding something to a queue,
> we have a real big problem.
> 
> Even queued destruction sound a bit dubious good idea - I keep
> resizing my window and the memory usage keeps going up? 

i think what he saw here was g_object_unref() always triggering
object destruction, which can very well happen with the way we
currently treat GCs. object destruction isn't very cheap, signals
are being emitted, parent type handlers are chained, data lists
get cleared up (callbacks) etc..
i don't expect putting g_object_unref() into an idle handler to make
a significant difference once we stopped creating and destroying objects
upon every window redraw.

> > >  * 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.
> > 
> > Opaque window resizing sucks currently because resizes are queued up
> > and not handled until the idle loop - essentially, Gtk is throwing
> > most of the ConfigureNotify events away instead of handling them.  My
> > guess would be that configure compression plus immediate resizes would
> > help, but I haven't tried it yet.
> 
> I couldn't see this effect at all on my machine, I did see (with my
> slower, earlier tests with debugging enabled) that I was triggering a
> pathology in the XFree86 scheduler on my machine. Try starting your
> server with -dumbSched and this behavior may go away.
> 
> Also, --disable-debug makes a big difference. Since we'll be
> shipping with debugging turned off unless we can fix the overhead,
> it may make sense to do performance with with --disable-debug.

eh? can you please first elaborate on the performance bottleneck in
 --enable-debug=minimum compared to --disable-debug?
 --enable-debug=minimum takes away most performance currently
consumed by debugging stuff, i don't really consider shipping
stable with --disable-debug an option, not if you take a look at the
warnings thrown out by the majority of gnome apps out there.

and even less so, considering that most people wait for us to throw
out stable and only then develop against gtk, it's a shame distributions
don't replace standard gtk library packages with --enable-debug=yes
versions once libgtk-dev gets installed ;)

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ