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 bottleneck. 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. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part