Extreme memory usage for gnome-panel related apps

[Andrew Farris]

Mark wrote:
> Now the notebook i'm typing this on has 1GB om memory and runs Fedora
> fine so if i look at it that way than the ram usage is fine. but keep
> in mind the people with less memory (256 or 512 MB's) they are gonna
> get a hard time with this fedora. My total memory usage at the time of
> this writing is: 432.00 MB (with GIMP on.. if that's closed than it's
> "just" 400 MB).

My P4 desktop system is currently showing 880Mb of memory 'in use' with 140Mb or
so free... and its doing nothing but playing mp3s from rhythmbox.  That actually
doesn't tell you much however, since its been running for a week and most of
that memory isn't actually being 'used' atm.  The machine has 144k of the 2Gb
swap 'in use'.  This is a good thing, nothing should be swapped if it doesn't
need to be.

> What i'm trying to say here is that those gnome-panel applets are
> taking up way to much memory regardless of the memory you can afford
> or have in your computer. It should just be as fast and small as
> possible with all the needed functions.

Yes, but who defines what are the needed functions and how much memory those
require?  Its not always simple choice to immediately release all memory used by
a program that isn't critical right now... I do not want clock cycles spent
recalculating things an application should have just stored for awhile.

> Gnome and Fedora are currently looking fine the way they are.
> so perhaps it's time to stop spending time on features for a while (2
> releases? till Fedora 10?) and start spending all time/money/efforts
> on performance  memory usage and usability.

These are mostly upstream issues for Fedora.  The tradeoffs of newer features
versus higher performance tweaking is always difficult, especially when the
people doing the programming have to do both... new features are usually more
fun to deal with.

Usability is at odds against performance and memory usage for the most part.
Having things preloaded, cached, etc, increases usability and overall polish.
When popping open a help window for instance, the faster it shows up the better
for the user.  If memory is used for some of the libraries it may depend on, so
it opens faster, that memory may seem wasted until you save the 2-3s waiting for
a window.

I don't mean to sound argumentative, but keep this in mind: working without X
uses less memory, but your memory isn't useful to you unless something
meaningful is being written on its bits... in a very extreme sense thats relevant.

> And again for the memory. Having much doesn't need that it needs to
> use much! slow pc's with less memory should be able to run fedora
> right? Simple example. imagine that a slow 500 MHz pc with 512MB
> memory wants to run Fedora + compizfusion + Gimp. Now at this moment
> he must drop compiz or gimp. if that panel stuff was just using normal
> amounts of memory he would have been able to use all 3 (just a
> example!!)

My HP Ipaq won't run compizfusion either... and development of fusion (and its
memory needs) shouldn't be held back by that.  A 500Mhz machine is clearly out
of the hardware target specs for 3d accelerated fusion.  While your main point
(reduce memory usage if possible!) is good, keep in mind that 12 year old
machines do NOT have to run the newest OS goodies 'well'.

I'm pretty sure a 500Mhz machine will perform adequately well with Fedora 8
running a light window manager such as blackbox, perhaps even XFCE4, but Gnome2
is asking too much IMO.

Also, looking at your system monitor window as is you're not getting a very
clear picture of what is going on with your memory just from that 'Memory'
column (maybe you already know this).  Add the other columns, especially shared,
resident, and virtual memory.  Look at the memory map (right click), sort by the
various columns, and you'll see that much of the memory shown as used is from
loaded libraries and caching (in the case of nautilus especially).  The 'bloat'
in a programs memory is going to show up as private memory not associated with a
file; there is where the program is storing most of own 'stuff'.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----