Re: GTK+ 2 speed

[Norm Reitzel <NormReitzel swbell net>]

On Thu, 28 Jul 2005 15:21:58 -0400
Owen Taylor <otaylor redhat com> wrote:

> On Wed, 2005-07-27 at 18:22 +0100, Robert Thorpe wrote:
> > Users of PCB are attempting to find out why the GTK+ version gPCB is
> > slower than the Athena version.  I'm also beginning to write a graphical
> > program and deciding which widget set to use, so I'm interested in the
> > same issue.
> > 
> > To help us both, it would be useful if anyone knowledgable on this list
> > could answer a couple of questions: -
> > 
> > * Are there any general reasons why GTK is slower than other widget
> > libraries?  Is it in fact slower, or is it just common
> > mis-configurations?
> 
> GTK+ is slower than Xaw because:
> 
>  - It displays things much more nicely
>  - It has good support for internationalization, accessibility, and
>    many other things that weren't on the radar when Xaw was designed.
>  - It has a much nicer programming interface
> 
> It's a "you get what you pay for" situation, really. Toolkits designed
> in the late 80's go really fast on today's hardware. On the other hand,
> they don't do a whole lot.
> 
> Our expectation and experience is that GTK+ performs decently for even
> complex applications on hardware from the last 5 years or so. If your
> app isn't performing OK, it's probably because you are doing something
> in particular that is slow.
> 
> 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.

> 
> > * 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.

-- Norm Reitzel

> 
> 						Owen
> 
>