After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 400100 - Implement mmap cache for desktop files.
Implement mmap cache for desktop files.
Status: RESOLVED OBSOLETE
Product: gnome-menus
Classification: Core
Component: libgnome-menu
2.16.x
Other All
: Normal normal
: ---
Assigned To: gnome-menus dummy account
gnome-menus dummy account
: 418963 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-24 06:31 UTC by Mathias Hasselmann (IRC: tbf)
Modified: 2021-05-25 12:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Mathias Hasselmann (IRC: tbf) 2007-01-24 06:31:32 UTC
Please describe the problem:
The Panel menu takes quite long to open. Even on high-end machines. I believe this could be solved by adding a simple mmap cache to libgnome-menu. It would contain all parsed desktop entries and would be read on startup to provide fast initialization.

Are we are using gtk's icon cache for resolving application icons?

Steps to reproduce:
1) Click "Applications" of the panel menu
2) Choose a submenu

Actual results:
It takes quite some time for the submenu to be populated and drawn. Specially icons take long.

Expected results:
The submenu to be drawn perfectly, instantly, as we know it from the big platform from Redmond.

Does this happen every time?
Yes.

Other information:
http://hughsient.livejournal.com/12033.html
Comment 1 Mark McLoughlin 2007-01-24 08:56:32 UTC
This, of course, has been discussed a number of times and I don't think we ever came to a solid conclusion. I'll try and dump what I remember of the discussions, but I'm quite vague on the details.

So, what the users sees in the applications menu is based on:

  - A users ~/.config/menus/applications.menu, 
    /etc/xdg/menus/applications.menu or an applications.menu from one of
    the paths in $XDG_CONFIG_DIRS

  - Any .menu file included from the toplevel <MergeFile>, and so on 
    recursively

  - Any menu files included via <DefaultMergeDirs> (e.g. all menu files in
    /etc/xdg/applications-merged) or <MergeDir>

  - Any .desktop or .directory files which are added to the available pool
    from the directories specified by <DefaultAppDirs>, <AppDir>, <LegacyDir>, 
    <KDELegacyDirs>, <DefaultDirectoryDirs> and <DirectoryDir>

  - The user's locale

The main bottleneck we're trying to eliminate is the amount of I/O time spent seeking to, and reading, the many .desktop files involved.

There are some differences from the case of the icon theme cache:

  - Every gtk app loads the icon theme, it's mostly just the panel that loads
    the menu - i.e. you don't have the memory advantage of many apps sharing
    a mmap cache

  - The contents of the .desktop files include a lot of translated strings

Let's try and iterate all the possible caching strategies:

  1) Each AppDir contains a cache of all the .desktop files entire contents,
     including translations. The cache is updated by e.g. desktop-file-install.
     One problem is that this could wind up being very large on some systems 
     (e.g. with GNOME and KDE installed)

  2) Same as (1) except translations are split out into individual message 
     catalogs

  3) Same as (1) except the cache would only contain .desktop file name, 
     categories and flags. The panel would load the actual .desktop files of
     the items in the resulting menu in order to obtain the remainder of the
     information.

  4) The cache would contain the final contents of the menu (e.g. .desktop 
     file path, name, comment, icon name, exec for each item), the mtime of
     all the files and directories involved, the $XDG_CONFIG_DIRS etc. env
     variables used and the locale. This would be cached the first time the
     user logs in (to e.g. /var/tmp to avoid NFS homedir issues) and the cache
     would be invalidated if anything changes and the whole thing reloaded.

I'm leaning towards (3). It's simple and it greatly cuts down on all that seeking.

(cc-ing alexl so see if he remembers more of the discussion)
Comment 2 Alexander Larsson 2007-01-30 13:40:09 UTC
I don't generally see much performance problems generating the menus. However, the icons take a fair time to appear. I'm sure the icon problem can be solved by not lazy-loading icons at the first time the menu appears.

Doing a mmap cache for this seems extremely complex, requiring changes to every application that installs a desktop files. I'm not sure its the right approach at all. It certainly needs some serious profiling to verify where the time goes.
Comment 3 Christian Kirbach 2007-03-17 11:27:12 UTC
*** Bug 418963 has been marked as a duplicate of this bug. ***
Comment 4 trapanator 2007-10-13 06:40:18 UTC
To me, the foot (ring on Ubuntu) menu is annoying slow. I have a Dell Latitude D800 with Centrino Dothan 1,7 GHz and 512MB of RAM, and I must wait 5-6 seconds to see the menu.

Note that, while it's loading, I cannot do anything: X11 is frozen! That's incredible...
Comment 5 Matt Behrens 2009-09-14 12:02:38 UTC
This is still a problem nearly two years later.  It does not cause X to hang on my Ubuntu Karmic system, but it is particularly troublesome nonetheless; not least because there is no feedback that work is being done.  The menu simply fails to pop for several seconds.  I've found myself clicking several times waiting for the menu to catch up.
Comment 6 André Klapper 2021-05-25 12:45:41 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new enhancement request ticket at
  https://gitlab.gnome.org/GNOME/gnome-menus/-/issues/

Thank you for your understanding and your help.