[Gllug] Re: What is the Gnome & KDE difference??

Wed Mar 29 17:06:26 UTC 2006

On Wed, Mar 29, 2006 at 05:35:06PM +0100, Richard Jones wrote:
> On Wed, Mar 29, 2006 at 03:42:46PM +0100, hrussman1 at ukonline.co.uk wrote:
> > Perhaps it simply
> > isn't possible to provide this kind of all-singing, all-dancing,
> > preconfigured, tightly-integrated desktop environment without being "fat,
> > bloated and slow".
> 
> Perhaps it's because I have a ridiculously powerful 64 bit desktop
> computer, but I don't find GNOME to be slow.  Bloated is another
> matter though:
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  8452 root      15   0  313m 202m 7104 S  0.0 10.1   1031:22 Xorg
> 26080 rich      15   0  320m 108m  19m S  0.0  5.4   9:01.64 firefox-bin
>  9379 rich      15   0  189m  56m 6708 S  0.0  2.8  20:03.47 gnome-terminal
>  9359 rich      16   0  222m  27m 7168 S  0.0  1.4   1:55.57 nautilus
>  9316 rich      16   0  115m  25m 4936 S  0.0  1.3  25:35.35 metacity
>  8792 rich      15   0 71856  17m 5564 S  0.0  0.9  43:39.89 skype
> 12020 rich      16   0  153m  14m 5396 S  0.0  0.7   0:22.47 evince
> 16691 rich      16   0 75892  13m 2332 S  0.0  0.7   0:22.71 xemacs
> 14625 rich      16   0 75756  13m 1960 S  0.0  0.7   0:14.44 xemacs
>  9437 rich      16   0  139m  12m 4628 S  0.0  0.6   6:08.63 wnck-applet
>  9355 rich      16   0  116m  11m 4444 S  0.0  0.6   1:01.55 gnome-panel
> 
> (Including X in there is a little bit unfair, because as we discussed
> on this list some time ago, much of the apparent bloat there is caused
> by memory mapping the display).
> 
> I did notice in the latest GNOME release notes that gnome-terminal is
> now apparently much smaller.  Which it bloody ought to be considering
> all it's doing is emulating a green screen terminal :-)  I wonder how
> much ROM/RAM those original terminals had ...
> 
> Firefox is "only" taking up 320 MB of virtual memory today because it
> routinely crashes, and crashed last time just yesterday IIRC.  Ah

Looking at the headline figure in the VIRT field doesn't really give much
useful information on how/if the application is bloated. Those 300 MB could
be attributed to anything from ELF libraries, through mmap()'d fonts, and
theme files, to heap / stack, and more besides. Some of this may be shared
across all applications on the system, some might be shared to a couple of
apps, some may be private. Finally it misses out memory stored by the X
server on behalf of the application - possibly many hundreds of MBs of 
pixmaps for all your open webpages

In investigating memory usage for the $100 laptop project I wrote a small
tool to display an app's memory usage broken down to the broad types of 
object:

  http://hg.fedoraproject.org/hg/olpc/tools/mem-monitor--devel/

And did a quick analysis on Epiphany...

  http://people.redhat.com/berrange/olpc/performance/epiphany/

Out of 450 MB of VIRT size of Epiphany:

 - 50 MB is locale-data (share by all apps)
 - 100 MB is ELF libs from /usr/lib & /lib (libc, Xfree, gtk, etc)
   mostly shared by all apps
 - 130 MB of heap/anonymous maps (genuine mozilla data bloat)
 - 65 MB of icons (shared across all desktop apps)
 - 55 MB of mozilla ELF libs (genuine mozilla code bloat)
 - 8 MB for VDSO page (placed by the OS, app has no choice in matter)

Ok, so that doesn't add up to 450 exactly, but you get the idea. Now would
I've not figured out yet is a way to identify exactly which memory pages are
shared vs private - I'm just guesstimating based on type of object. 

Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20060329/379108ef/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug