Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157597 - slow Desktop menu on ppc (2.5 sec) vs i686 (<1 sec)
Summary: slow Desktop menu on ppc (2.5 sec) vs i686 (<1 sec)
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-panel
Version: 4
Hardware: powerpc
OS: Linux
Target Milestone: ---
Assignee: Mark McLoughlin
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-13 01:34 UTC by John Reiser
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-16 11:23:26 UTC

Attachments (Terms of Use)

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):

How reproducible:

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.

Additional info:


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.

Note You need to log in before you can comment on or make changes to this bug.