Re: [Nautilus-list] Nautilus and memory usage (performance issue)

[Jason Tackaberry <tack linux com>]

> An impressive fix, decisively cutting to the source of the problem
> (problem between keyboard and chair...).

There clearly are resource issues with Nautilus, but the memory problem
just isn't as bad as you first thought. :)

> Is there a "usefulness" reason for this reporting style? Or is that just
> historical / technically most feasible way to display process memory
> usage?

Part of the issue here is not so much with shared libraries, but with
multiple threads.  gtop groups together all the Nautilus threads into
one bar called "nautilus."  When you look at top:

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1194 tack       9   0 10452  10M  6552 T     0.0  2.7   0:02 nautilus
 1224 tack       9   0 10452  10M  6552 S     0.0  2.7   0:00 nautilus
 1225 tack       9   0 10452  10M  6552 T     0.0  2.7   0:00 nautilus
 1226 tack       9   0 10452  10M  6552 T     0.0  2.7   0:00 nautilus
 1227 tack       9   0 10452  10M  6552 T     0.0  2.7   0:00 nautilus
 1228 tack       9   0 10452  10M  6552 T     0.0  2.7   0:00 nautilus
 1229 tack       9   0 10452  10M  6552 T     0.0  2.7   0:00 nautilus

Notice there are 7 threads here.  Nautilus' memory usage really isn't
all that bad.  gtop adds up all the RSS values and reports that.  So
gtop thinks Nautilus uses 73164kb of RAM.  It can't (or at least
doesn't) tell whether these are separate processes, or separate threads.
Obviously it assumes they're separate processes.

So in Nautilus' situation, gtop's memory usage summary isn't really
informative.  As Maciej pointed out, this summary also isn't taking into
account shared memory, like the gtk+ and gnome libs.  It sure isn't fair
to roll all the memory used by these libraries into Nautilus.  So a
rule-of-thumb method to determine the _actual_ memory used by a process
is RSS-SHARE.  For Nautilus "proper" this is 3990MB.  Not bad at all.
Naturally this goes up as one uses Nautilus.

Cheers,
Jason.