RE: GTK+ 2 speed

On Fri, 2005-07-29 at 13:44 +0100, Robert Thorpe wrote:

> > 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.
> I understand that to some extent this is inevitable, though Windows does
> #1 and #2 of your list and still manages to be fast even on old
> hardware. (Windows XP of course doesn't but earlier versions do).

GTK+ has pretty good feature parity with XP in these areas. And roughly
speaking GTK+ on X performs comparably to XP as well. Some things are
definitely slower. A few things might be faster...

> If a program doesn't use the features you mention, like Pango and
> Unicode etc will the program go faster?

You can't not use these features; they are built right into the
core and all text goes through them.

> > 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.
> I'm basing my experiences mostly on using Gnome on Xfree86, not on
> anything I've written myself.  I haven't actually started writing the
> *nix GUI of the program I mentioned, I'm only planning it.
> Gnome doesn't work quickly on my two year old 1.6GHz Duron.  Does anyone
> know if is Gnome well designed in this regard?

"GNOME doesn't work quickly" is a fairly broad statement. To really
comment on that, I'd have to know more specifically what was slow
for you.

In general, I think GNOME uses GTK+ in a reasonably efficient manner,
but GNOME is a complex system that goes well beyond GTK+ with complex
components like gnome-vfs, GConf, and so forth.

As a data point people on low resource machines (1.6Ghz isn't low
resource) have reported good results with GTK+ and alternate light-
weight desktop environments like XCFE.

> > 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.
> That's a very useful thing to know.
> > > * 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.
> That's also useful to know.
> But, what I was asking was: Does event handling involve long string
> comparisons?  Someone told me that is does and this causes problems in
> the specific case where you're creating a lot of events.

Event handling does not involve long string comparisons. Signal handling
(in GTK+, only things like button presses are called "events") is a
complex operation, and that causes some performance issues; it's
not as fast as I'd like by any means. (Give me a spare month, and I have
some ideas...)

But if your application needs to handle less than say 
100,000 signals / second than signal handling isn't going to be a

What I'd say is:

 GTK+ performs quite well for many complex applications: GIMP,
 gnumeric, inkscape,  evolution, etc. It is seldom the case that the
 overall performance of the app is bounded by the performance of GTK+.

If people run your PCB application on 64 megabyte 200Mhz machines - then
I'd worry about GTK+ performance first. If people are using it on
reasonably modern machines, I'd worry first that your users are 
currently being subjected to Xaw.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]