Created attachment 2666 printf() test. 1) Add Xfce Menu to panel 2) Repeatedly click the menu at double-click speeds 3) After a few iterations, the CPU usage goes to 100% for some time What appears to happen is that there are a gazillion dbus messages being sent. Adding some printf() information to xfdesktop4/modules/menu/desktop-menu.c, xfce_desktop_menu_populate_menu_impl(), as in the attachment, shows that: - under normal operation "Hello1" happens as is should - repeated clicking causes the program to enter the "Hello2" block and that's where the high CPU usage happens. My guess is that the menu cache is forcibly regenerated if the menu is closed before it shows up, or something along those lines.
Furthermore, once it gets into the cache-regenerating state ("Hello2"), it never only goes down that code path.
(In reply to comment #0) > 1) Add Xfce Menu to panel > 2) Repeatedly click the menu at double-click speeds > 3) After a few iterations, the CPU usage goes to 100% for some time Then... don't do that. > What appears to happen is that there are a gazillion dbus messages being sent. The menu doesn't use dbus.
(In reply to comment #2) > > 1) Add Xfce Menu to panel > > 2) Repeatedly click the menu at double-click speeds > > 3) After a few iterations, the CPU usage goes to 100% for some time > > Then... don't do that. You don't consider it pretty serious that if the menu is accidentally triple-clicked, it forever goes into a state that it recreates the entire menu every time it's opened, taking over 10s on a slow computer? The normal behaviour on the same unit is an instantaneous menu popping up. > > What appears to happen is that there are a gazillion dbus messages being sent. > > The menu doesn't use dbus. I know it doesn't directly, but could there be something it's linking against? strace definitely shows the process spinning a lot of xfconf messages...
(In reply to comment #3) > (In reply to comment #2) > > > 1) Add Xfce Menu to panel > > > 2) Repeatedly click the menu at double-click speeds > > > 3) After a few iterations, the CPU usage goes to 100% for some time > > > > Then... don't do that. > > You don't consider it pretty serious that if the menu is accidentally > triple-clicked, it forever goes into a state that it recreates the entire menu > every time it's opened, taking over 10s on a slow computer? No, not really. It's not the best behavior, of course, but it's better than no caching at all. > The normal behaviour on the same unit is an instantaneous menu popping up. I can't dupe this on my machine, no matter how fast I click it, but I do have a pretty fast machine. > > > What appears to happen is that there are a gazillion dbus messages being sent. > > > > The menu doesn't use dbus. > > I know it doesn't directly, but could there be something it's linking against? > strace definitely shows the process spinning a lot of xfconf messages... The menu plugin doesn't link against xfconf, even indirectly. Check for yourself (ldd $libexecdir/xfce4/panel-plugins/xfce4-menu-plugin). You must be looking at the wrong process or something. In the future, please just report the symptoms. False diagnoses merely waste my time, and yours. Thinking about this a bit more, this behavior is correct in a sense. The cache is recreated only after the old menu is destroyed, which happens in an idle handler after the menu is withdrawn from the screen. It's certainly possible, if you're fast enough (and your machine is slow enough), to click on the button again before it's even started recreating the menu cache. Now, for the menu *plugin*, there really doesn't need to be this complicated cache mechanism, because the plugin doesn't have to do with the dual-menu system from xfdesktop, so in theory it could keep the menu around forever (well, assuming it never changed) and just keep reusing the same one over and over. However, that would complicate the code quite a bit, and I don't think it's worth it. But this might get fixed as a side-effect of some other menu system changes that are on my TODO list. Depends on how the implementation goes, or if I get to it.
Actually, this is invalid altogether. My version of the code had a stupid patch that added xfconf to have a preference whether to show Name or GenericName. For every menu item it was querying this flag. Suffice it to say, not an upstream problem.