|Summary:||slow Desktop menu on ppc (2.5 sec) vs i686 (<1 sec)|
|Product:||[Fedora] Fedora||Reporter:||John Reiser <jreiser>|
|Component:||gnome-panel||Assignee:||Mark McLoughlin <markmc>|
|Status:||CLOSED WORKSFORME||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-05-16 11:23:26 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description John Reiser 2005-05-13 01:34:51 UTC
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): gnome-panel-2.10.1-9 How reproducible: Always 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. 3. 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. Additional info: kernel-2.6.11-1.1290_FC4
Comment 1 Mark McLoughlin 2005-05-13 12:23:24 UTC
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 ?
Comment 2 John Reiser 2005-05-13 14:18:53 UTC
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.
Comment 3 John Reiser 2005-05-13 22:21:11 UTC
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 the next. 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.
Comment 4 John Reiser 2005-05-13 22:38:51 UTC
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?]
Comment 5 Mark McLoughlin 2005-05-16 11:23:26 UTC
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 > /dev/null If there's the same kind of variance between machines, then its the disk that's the problem. 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.