Performance tuning the Fedora Desktop

[Warren Togami]

Will Cohen wrote:
> I work on performance tools at Red Hat. I have been told there is
> interest in tuning the desktop to improve performance. I have a number
> of questions to help identify the work needed in this area. I would be 
> interested in any answers that people have for the following questions.
> 

On a somewhat related topic of desktop performance, recently fedora.us 
Extras has begun experimenting with -Os rather than the standard -O2 
optimization for our firefox & thunderbird packages.  So far it seems to 
be working very well, with noticably smaller binary RPMS and runtime 
memory footprint of these two very large applications.  I asked gcc 
developers if they had a guess about which -O2 and -Os would be "faster" 
for large applications like firefox & thunderbird.  They generally 
replied that they have no idea, because compiler optimization is an 
inexact science.  All kinds of other factors come into play like smaller 
memory footprint (less swapping), smaller code size (maybe better use of 
CPU cache).

Have there been any past discussions about changing the standard 
compiler optimization for perhaps FC3?

> 
> What specific performance problems have people observed so far in the
> desktop?  For example heavy CPU or memory usage by particular
> applications. Another example long latency between event and resulting
> action.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100423
One long standing desktop bug that has annoyed me personally is 
Evolution's extreme performance problems when dealing with a large 
amount of mail in dozens of IMAP folders.  It literally takes MINUTES 
for evolution-1.4.x or evolution-1.5.x to start and read the first 
message in any IMAP folder due to this problem, while Mozilla, 
Thunderbird and KMail show new mail almost instantly.
(This report also describes an unrelated 100% CPU usage in resizing 
panes horizontally.)

Aside from Evolution, I personally see rpm's huge memory footprint as 
being a huge problem.  Recently I did a full upgrade of FC1 "Everything" 
to FC2 in a single rpm transaction on a box with 256MB RAM.  It took 
almost 7 hours due to a massive amount of swapping as rpm's memory 
footprint climbed past 400MB.  We really need to improve this situation. 
  I would ask for optimization of rpm's memory footprint to be a high 
priority for FC3 timeframe, but it may be too scary of a problem. =(

On a somewhat related note, the rhn-applet uses more than 30MB of 
virtual memory.  That is just WAY too big.  Also look at its CPU time 
after a few days running.  The combined time of it doing *something* 
seems a bit too much IMHO.


Aside from individual applications that need fixing for severe 
performance problems like the above examples, I see our current desktop 
software has having poor or lacking behavior in the area of application 
usage feedback as being a severe usability weakness.

Currently we have somewhat acceptable Application Startup Feedback in 
both GNOME  and KDE when programs are launched via panel or menu 
launchers from .desktop files.  The cursor changing to an hour glass or 
otherwise showing motion and activity when you launch "mozilla" gives 
the user the feeling that "something is happening" and they must wait. 
Without application startup feedback, users click on the launcher 
several more times, and bad things happen.

Application Startup Feedback is today not perfect in both GNOME and KDE. 
  It all cases that I am aware of, launching an application from another 
(i.e. URL handler in gaim) does not trigger the mouse cursor to show 
activity.

This is somewhat related to what I feel is another huge related weakness 
in our current desktop software: Application Busy Feedback.  Within 
applications, users expect feedback from various operations to indicate 
that various apps, or parts of apps are busy doing something.  Windows 
seems to have two levels of "busy" feedback.  One with the tiny 
hourglass next to the pointer, and another with the entire cursor 
turning into an hourglass.  I personally see that is quite effective 
when applications embrace this type of functionality in a fine-grained way.

I am not a desktop developer, so I don't know much about the technical 
guts under the things I described here.  Any explanation, links to 
specifications, and mention of future development related to Application 
Feedback would be appreciated.

Warren Togami
wtogami at redhat.com