Performance tuning the Fedora Desktop

[Will Cohen]

Warren Togami wrote:
> 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).

It is quite possible that the saving in space could give significant 
performance benefits. Code fitting better in instruction cache, fewer 
page misses, and paging could be a large win than getting some inner 
loop to run faster.

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

I have seen some discussions on -Os vs -O2, but I haven't seen actual 
performance comparisons.

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

Jeff Johnson has mentioned the performance problems with the rpm 
internals to me before.

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

30 MB? Do you have anymore details on that, e.g. space for code and 
data? Where there just a huge number of libraries being pulled in?

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

Response time for actions has come up in a number of the responses to my 
mail. If the response was very fast, then the feedback wouldn't be an 
issue. However, given the response times, it appears that the system 
isn't reacting to the input.

Some developers have used strategic printf and accesses to get data out 
like how long it took to get from here to there. Another thing we might 
consider is the ability to start and stop oprofile sampling at 
particular places in code. For example, instrument the code to start 
oprofile sampling on a particular action and then stop oprofile sampling 
on another event. This would avoid interesting data getting buried in 
the long term data. Using oprofile in this manner would give a better 
picture of what sections of code are getting exercised for certain actions.

-Will