RE: GTK+ 2 speed

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

> -----Original Message-----
> From: Owen Taylor [mailto:otaylor redhat com] 
> 
> On Fri, 2005-07-29 at 13:44 +0100, Robert Thorpe wrote:
> 
> 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...

Yes, though I was comparing to older versions of Windows really, which
are as good as XP but 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.

For what I'm doing I have little chance of ever getting a non-english
speaker to provide me with any translations.  Even if I did, I doubt a
non-english speaker would ever use the program. So I don't need the
internationalization features, or the text layout features.

If it isn't possible to write a program without Pango then that's a
disadvantage for my program.  Since going though Pango means going
through more code it means possibly lower performance and possibly
problems from bugs in that code.

This is not a big disadvantage though.

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

To be specific, redrawing is slow.  Moving from a terminal to X with
Alt-Ctrl-F7 it takes a couple of seconds for all the widgets to redraw
themselves.

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

I'll try that and see what happens.

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

That's good to know.
 
> 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+.

Again, that's useful to know.  I'm trying to avoid having to hack around
deficiencies in the GUI library as I've had to do in programming I've
done in the past.

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

I think I've confused you, there are two programs here: The one I'm
working on, which has no X interface yet and has nothing to do with
printed circuits.  Then there is PCB, a program written for pcb design
by lots of other people who aren't me.

I was asking this question because it's of interest to me and
users/developers of PCB whom I'm going to pass my findings to.