Skip navigation.
home | news feeds | archives | search | forums | submit news
Home

O'Reilly article on current GNOME optimisation work

Submitted by Uraeus on Wed, 2005-11-02 12:11. GNOME
GNOME

Jono Bacon have written a nice article on the O'Reilly network discussing the current set of optimisations work being done on GNOME. The article focuses on the work by Federico Mena-Quintero who started the effort with his work on speeding up the GNOME file chooser. Today this effort seems to be picking up speed with people such as Billy Biggs, Carl Worth and Behdad Esfahbod all working hard on various performance issues. In addition to that Nokia have sponsored some performance related work through their Maemo effort. Anyway, you find the article from Jono here and you can follow the optimisation effort live on Planet GNOME

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Preloading

Submitted by Anonymous George on Fri, 2005-11-04 10:30.

I liked Michaels comments on preloading. I think it's a mistake - one that has absolutely killed performance on Windows. If you preload stuff, you increase startup times - period. If you reduce the number of things that need to be loaded it can actually help. If you think preloading stuff is a good idea, consider what startup will look like when: The Pannel, Several Applets, Evolution, Firefox, OOo, and some misc other apps decide to load and preload on startup. Now consider the case where you just want to fire up the machine and play some BZflag for a bit and don't want to use any apps. It sucks 4$$. Or if you just need to check email quick... When you start preloading, it's a sign that you didn't do the right optimizations - because you don't know what they are.

There are different areas of programming, and people can't be expected to be good in all of them. Performance optimization should not be taken lightly. You start at the bottom - optimize your apps so they load fast and run fast. Do not start at the system level and try to compensate for a bunch of slow apps with hacks like preloading. Don't start at the app level either - there are components of the app that were designed poorly (from a performance perspective) and should be fixed. If you've got 1GHz machine, there is no reason for any UI component to be unresponsive. If you're saying "but..." you should think about that specific area you were going to justify being slow - too many people beleive things have to be the way they are "just because". I'm not trying to flame here, it's a normal thing most people need to get over - myself included sometimes.

That said, I hate that the main menu takes several seconds to pop up the first time it's clicked. I run FC4 and this was not the case in FC3. All I can figure is that the menu items and icons need to be read off disk and this happens after the first click. OTOH, submenus pop right up after that. Not sure what the problem there is - preloading seems like it might help, but perhaps the whole menu is preloaded on that first click and preloading IS the problem. I really don't know because I don't hack on gnome - I just use it. I do look forward to any good memory or performance optimization people can contribute.

Thanks guys

which version of gnome-panel? by Anonymous George
"...speeding up the GNOME by Anonymous George

ummm...

Submitted by Anonymous George on Wed, 2005-11-02 22:57.

You may not have noticed, but Gnome uses Gtk. Therefore, a simple process of deduction says that a speedup of Gtk implies a speedup of Gnome. That and there is a concerted effort to speedup Gnome itself. There is Federico's work on Gedit/gnome-terminal, some work on nautilus, some work on gnomey libraries (like libgnomeui) that are being integrated into gtk, and the work done over the summer by the intern who tried to quicken the startup process. So, aside from being pedantic and wrong what have you accomplished today?

Actually...

Submitted by Anonymous George on Thu, 2005-11-03 07:12.

What I'm trying to say is that the filechooser does not belong to GNOME but to GTK. It'd be one thing if the article read, "Yeah, so there's work being done on many parts of GNOME, such as GTK, etc. These upstream benefits will (happen to) improve GNOME's performance." The article implies that only GNOME users will benefit, that the reason these things are being worked on is because they belong to GNOME, but these implications miss the fact that Xfce uses GTK just as much.

I'd be just as upset if some Xfce material claimed that Federico was doing work to improve its performance because he was working on the Xfce filechooser. "Xfce != GTK" But I don't hear any Xfce people who have the microphone talking that way, and I am just as quick to correct those who talk that way on the mailing list and in IRC.

My name's not George,
Andrew Conkling
http://aconkling.blogspot.com

This is gnomedesktop.org

Submitted by Anonymous George on Thu, 2005-11-03 10:16.

This is gnomedesktop.org. The work is being done to improve GNOME. It's nice for XFCE if it helps them too, but don't expect us to care much about that.

Way to miss his point. by Anonymous George

They're hitting everything

Submitted by Anonymous George on Wed, 2005-11-02 14:31.

Gnome-Terminal
GEdit
GtkFileChooser
GtkTextView
Pango
Cairo

These guys are ripping through EVERYTHING digging out the performance problems.