Bug 338024

It used a few hooks to the file system so that if applications are installed, it will know and update accordingly. It also have the status area where it shows you information about disk space and connectivity.
Updating these sort of things only once you click on it would lead to delays as it would have to update it then, and that would most certainly annoy you.

Please explain why the current CPU cycles used is a problem.

> Please explain why the current CPU cycles used is a problem.

CPU cycles == battery time.  A busy main-menu means the computer is less
useful for travel.

But seriously, did you take a look at what main-menu really does?  Throw
strace at it and observe:

* It reads /proc/mounts and /proc/partitions. It then stats everything mentioned in there.

* It appears to be talking to NetworkManager via dbus.

* It stats about 100 directories like /usr/local/share/icons

And it does all of those every few seconds!


If it wants to know when some files change, then it should arrange for a
wakeup call when they do.  inotify should work for that.

There's no clear problem to be solved in this bug, so I'll close it.  For examples of better-documented performance problems, see bug #349357.

There must be something strange in the water.

Let me see.  Bug 349357 is a tracker bug thus has no information itself.
It depends on three bugs:

230478: I cannot access this one.
338024: This bug.
348183: A bug about startup time.

Federico, could you please explain -- in short simple words that I can
understand -- how this bug, which is about cumulative resource usage
and the fact that main-menu wakes up every few seconds even though I
have not pressed its button/mucked with the network/attached new disks,
is somehow covered by 349357?

Are you unable to reproduce this unreasonable behaviour?

(In reply to comment #2 from Morten Welinder)
> > Please explain why the current CPU cycles used is a problem.
> 
> CPU cycles == battery time.  A busy main-menu means the computer is less
> useful for travel.
> 
> But seriously, did you take a look at what main-menu really does?  Throw
> strace at it and observe:
> 
> * It reads /proc/mounts and /proc/partitions. It then stats everything
> mentioned in there.

Not sure about this, I doubt its direct work in the menu but probably unnecessary work.

> * It appears to be talking to NetworkManager via dbus.

Yes, its probably polling for state and doing it all the time rather than just on open.  The problem as I recall is that stacking up a bunch of stuff for work can then cause the menu to take a long time to open, so this will have to be but in a thread presumably (and maybe figure out a way not to blink icons or have UI inconsistencies).

> * It stats about 100 directories like /usr/local/share/icons
> 
> And it does all of those every few seconds!
> 
> If it wants to know when some files change, then it should arrange for a
> wakeup call when they do.  inotify should work for that.

For applications the gmenu library from gnome-desktop is used.  I think its using inotify underneath.

Hehe, maybe my trigger finger got too twitchy :)

I'm working on the thumbnailing part --- it seems that main-menu is generating thumbnails for everything in your recent-files, which it should definitely not do.

I was about to file this same bug, but searched and found this one, so I'll just throw a "me too" in here.  

On my laptop running 10.3, when the system is otherwise idle, main-menu is nearly always on the top of the list, usually using double-digit %cpu.  Seems kind of silly. 

Also, does it really need 66MB RAM? 

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3627 bart      15   0  144m  66m  13m S   15  3.3 141:58.41 main-menu

And constantly growing...

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3627 bart      16   0  174m  94m  13m S    9  4.7 348:59.93 main-menu

*** This bug has been marked as a duplicate of bug 230478 ***