Performance tuning the Fedora Desktop

[Dan Williams]

Hi,

The Menu VFS code has to do a number of things when the panel first
reads it as well:

1) Locate and read all .menu files in /etc/xdg/menus
2) Parse these menus and locate all .desktop/.directory directories
3) Parse all .desktop/.directory files from (2) to find out their
categories, names, and OnlyShowIn values
4) Create the actual menu structure from the data in (2) and (3)

There is definitely room for improvement and optimization here in the
menu code, but 1 - 4 have to happen in any case, which includes a lot of
hitting the disk.  So if you're doing something disk intensive at the
time you first click, it might take a couple seconds.  Also, if the
directories or files in (1) and (2) get touched or changed, the whole
menu structure is currently rebuilt to make it aware of changes, which
means invalidating a lot of cache and reloading many bits of info.

Dan

On Tue, 2004-05-11 at 13:30 +0100, Mark McLoughlin wrote:
> Hi,
> 
> On Tue, 2004-05-11 at 13:30, Alexander Larsson wrote:
> > On Fri, 2004-05-07 at 17:08, Julien Olivier wrote:
> > > On Wed, 2004-05-05 at 22:11, Will Cohen wrote:
> > > And, from time to time, clicking on the main menu takes ages to display
> > > the menu (where ages really mean up to 10 seconds)
> > 
> > I think the panel loads the menu "on-demand" to save memory, and once
> > its loaded its forgotten if not used for a while. Or something like
> > that.
> 
> 	I haven't quite figured out whats going on here yet. There are a number
> of options:
> 
>  1) We check and re-read the menu on click
> 
>  2) The menu has been swapped out by that stage
> 
>  3) Destroying the GTK+ menu takes a long time (this was a problem at 
>     one point with GTK+ 2.3.x, but that got fixed)
> 
> 	It needs profiling.
> 
> Cheers,
> Mark.
> 
> 
> -- 
> Fedora-desktop-list mailing list
> Fedora-desktop-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-desktop-list