RE: GTK+ 2 speed

["Robert Thorpe" <Robert Thorpe antenova com>]

> -----Original Message-----
> [mailto:gtk-list-bounces gnome org] On Behalf Of Norm Reitzel
> On Thu, 28 Jul 2005 15:21:58 -0400
> Owen Taylor <otaylor redhat com> wrote:
> > One possibility is text measurement ... text measurement is "free"
> > in the Xaw universe, so a lot of apps designed for that repeatedly 
> > relayout and remeasure the same strings, or measure a huge 
> amount of 
> > text in a blocking operation. Profiling may show where your app is 
> > having difficulties.
> 
> Let me emphasize something that  Owen has said more or less 
> off the cuff.  You simply cannot tell where an application is 
> spending its time if you don't profile the code.  In my 
> thirty years (yes) of writing code, I have repeatedly watched 
> people waste hordes of time shaving microseconds in pieces of 
> code that are miniscule fractions of overall performance.
-snip-
> > > * Also, is it true that GTK must handle many events by performing 
> > > long string comparison operations?  Does this cause a slowdown?
> > 
> > String comparison is not a big expense in GTK+ operation.
> 
> And this is the classic example.  Yes, GTK does do "long 
> string comparison" operations when handling events.  People 
> are forever claiming that "this is slow" without ever 
> actually looking to see what fraction of code time is spent 
> performing this "lengthy" operation.  Before you decide that 
> something is "obviously" slow - measure it.  You might be 
> quite surprized.

I agree that there is no point guessing how to optimize an application,
that quite true.
Much code I written gives almost no thought to performance, and doesn't
need to.  If performance ever becomes an issue I can fix it later.

However, I can't fix code in third-party libraries like GTK+.  So it's
worth thinking about the issue upfront.

As an example, I maintain an MS Windows program that displays many items
in a sorted listbox.  Sorting a listbox in Windows is expensive, for a
long list very expensive.  So I'm in the process of writing an elaborate
workaround involving storing all the information elsewhere.  It's very
useful to know about these problems beforehand.

(Even if it is fast I'm still rather puzzled why GTK+ uses strings for
event handling)