Red Hat Bugzilla – Bug 157597
slow Desktop menu on ppc (2.5 sec) vs i686 (<1 sec)
Last modified: 2007-11-30 17:11:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.7) Gecko/20050509 Fedora/1.0.3-5 Firefox/1.0.3
Description of problem:
On PowerPC (Mac mini 1.25GHz, 512MB), the top panel Desktop menu [the one with Preferences, ..., Lobout] takes about 2.5 seconds to draw after Button1 down. On i686 (Athlon 1.1GHz, 768MB) the same Desktop menu takes less than 1 second to draw. Thus the PowerPC version seems unreasonably slow. (This is for first invocation; the second invocation takes less than 0.5 second on both.)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot to multiuser graphical mode; log in.
2. Press Button1 on the Desktop menu in the panel at the top of screen, and time how long the menu takes to appear.
Actual Results: On PowerPC Mac mini, it takes about 2.5 seconds.
On i686, it takes less than 1 second for the menu to draw.
Expected Results: PowerPC should also take less than 1 second to draw the Desktop menu.
By any chance is the ppc install an "everything" install and the i686 one isn't?
what does "ls -l /usr/share/applications | wc -l" give on each ?
Each box was installed as "Workstation" (software development), and neither
desktop has been customized.
The i686 shows 120 applications, and the ppc also shows 120 applications.
Changing from "defaults" to "defaults,nodiratime" in /etc/fstab has no effect [1
filesystem only: / (root)].
Booting the i686 with mem=512M (to equal the RAM of the ppc) slows the i686 to
about 1.5 seconds between Button1 on Desktop in menu bar, and the appearance of
that menu. This is still about 1 second faster than PowerPC Mac mini.
Running "vmstat 2" in a Terminal window and looking at the output while pressing
Button1 on Desktop in the menu bar, the i686 gets bi=582 in one sample,
surrounded by samples of 0. The ppc gets bi=480 in one sample, then bi=180 in
From /var/log/messages, the Mac mini disk is:
hda: ST940110A, ATA DISK drive
hda: 78140160 sectors (40007 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
and 'df' says:
/dev/hda4 10736544 5016544 5165812 50% /
Both boxes timeshare the CRT, so I will reboot to gather the data about the i686.
From /var/log/messages, the i686 disk is:
hda: WDC WD1200JB-00DUA3, ATA DISK drive
hda: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100)
and 'df' says:
/dev/hda7 5679848 2528460 2858204 47% /
So the i686 in-disk cache is 4 times as big as the ppc: 8MB to 2MB. This could
account for some of the difference. But the Desktop menu has only 6 items
(Preferences, System Settings, Help, About GNOME, Lock Screen, Logout.) Do all
the deeper levels have to be computed before these 6 are drawn? [Why?]
Yeah, its probably down to disk performance or layout. There's a lot happening
when you click on the button - basically every .desktop file on the system is
loaded and processed according to the files in /etc/xdg/menus
Try this on both machines:
time cat /usr/share/applications/*.desktop /usr/share/applications/kde/*.desktop
If there's the same kind of variance between machines, then its the disk that's
Things will probably be better with FC4 final, because /etc/readahead.files will
be updated with the latest list of .desktop files read by the panel.
Anyway, I'm going to close this on the assumption that the disk performance is
what accounts for the difference.