Comment 4 for bug 24669

I couldn't open the link to upstream, not sure if it's a temporary problem.

This and bug #44002 are probably instances of the same problem: the first time the menu is displayed, and after a change, it is completely regenerated. It looks very bad, because it feels like the whole interface froze. (It doesn't, but since the user's focus is on the menu, it seems that way.)

I know the menu is regenerated on changes, but there's no need to regenerate the entire menu. Most of the time there's only one or two entry added/removed. The menu should be displayed from the cache, and only the changed items should be modified.

Even more, usually the change is in a sub-menu, so we might have time to add/remove it before the user reaches it. Anyway, removing or adding an entry after the menu is displayed would be much less annoying than having the whole menu freeze for five seconds or more.

Another idea would be to monitor the directories in the background when possible (there's a kernel extension for that) and add the entry even before the user clicks the menu.

The delay also appears when the user clicks for the first time the menu, _each session_. Someone said fixing this would add a startup delay, but that's wrong. The right way is to cache the last-used menu (before the shutdown), and do just an incremental update at start-up.

Second, we could populate the menu in the background, on a low-priority thread. This way the start-up is not greatly affected. (And the system is a bit unresponsive at the start, anyway, so the menu wouldn't be noticed.)

Since dual- and multi-core processors are more and more common, parallel start-up should be much more often used.