xfce4-panel & memory cunsumption

[Benedikt Meurer]

Kresimir Spes wrote:
>>There is this one idea that I had that may be interesting for 4.6:
>>make all plugins internal for their GUI part (buttons, icons, progress
>>bars), but use a separate progress to collect and manipulate data.
>>  
> yeah, that is a good idea, though it might limit some of the functionality, but 
> it would drasticly drop down memory consumption.
> well, I'm glad to hear things are looking up :)

You have 1GB of memory and care for a few kilobytes that are "wasted" by
plugins? And would rather sacrify stability and flexibility of the panel
for a few kilobytes?

Note that the raw numbers you have brought up mean nothing in a paging
system, as I told you already. That's just what the kernel "knows", but
not what the application really uses. If nothing changed recently, glibc
does not return unused memory to the kernel, so for Linux, the numbers
mean even less. If you really want to know what memory is used and
where, you'll need to do a memory analysis of the application.

The slice allocator in GLib 2.10 and above makes the situation even
worse as a lot of memory is not even returned to the malloc
implementation. But that doesn't mean the application really uses this
memory. It's just the upper limit at a given time in the past. The
kernel may swap out unused pages if memory is needed (which is unlikely
to happen anytime soon with Xfce on an 1GB i386 system, and no sane
kernel will start swapping out large amounts of memory if more than
512MB are still available).

Numbers don't mean anything if you are unable to interpret them
appropriately.

In addition, for "lightweight", that does not mean "shows up with only a
few bytes of 'Writable Memory' in gnome-system-monitor". That may be
your understanding of "lightweight"... But "lightweight" means that the
desktop is responsive and uses only a moderate amount of system
resources. Note that there's an important different between "uses" and
what shows up in gnome-system-monitor.

Benedikt