GNOME Bugzilla – Bug 400100
Implement mmap cache for desktop files.
Last modified: 2021-05-25 12:45:41 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
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)
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.
*** Bug 418963 has been marked as a duplicate of this bug. ***
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...
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.
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.