On Tue, Jan 16, 2007, Tzafrir Cohen wrote about "Re: Why are GNOME applications 
(and applets) take so much [EMAIL PROTECTED] memory ?":
> > My opinion: Some serious debate needs to be occured, whether in
> > slashdor or the mailing lists, some sort of "shake up" in the
> > GNOME/KDE development community, to remind them that this situation
> > cannot be continue, and some diet is required.
> 
> OpenOffice and Firefox are not developed by either gnome or KDE.

They are not developed by Gnome or KDE, but they are based on the same
monolithic if-we-take-up-a-lot-of-memory-the-users-will-just-buy-more
philosophy. For the life of me I can't understand why XEmacs, the original
"kitchen sink" that tries to do everything for everybody, takes memory in
the order of 10-20MB, and OpenOffice often takes 10 times more.

> Actually it seems that KDE apps are reasonably efficient.

Let's compare a few clock applications:

app                     VIRT    RES     NOTE
xdaliclock              3756    796
oclock                  3632    1540
xclock                  8544    2976
kclock.kss              25840   8164
clock-applet (Gnome)    90212   11256   (only the applet process)
clock_panelapplet (KDE) 33664   12028   (for "kicker" with only a clock applet)

This is nothing short of ridiculous. These "integrated" enviroments may be
great for new users, but I can't for the life of me understand the
justification of using so much memory for a clock applet. Even "xclock"'s
memory use surprised me, and it is just a third of what the KDE/Gnome
applets appear to use.

P.S.
Offering some insight on why Gnome's VIRT figures are huge, which was the
question that started this thread:

Trying to understand where Gnome's clock-applet's huge VIRT comes from,
I discovered something very interesting. It start with just 28 MB of VIRT,
but at the moment you right-click on the clock, and a menu pops up, it grows
to, belive it or not - 90 MB. That's 60 MB to show a menu !?
I diffed the /proc/../maps, and this is what the extra 60 MB contain: 0.5 MB
of newly allocated memory, plus a lot of mapped files; One interesting mapped
file is the HUGE /usr/share/icons/crystalsvg/icon-theme.cache, taking up 28 MB
of mapped space!
But as I suspected, out of this 60 MB, most is read-only and mapped from files
and thus takes up *zero* ram, and *zero* swap space. Other than giving a huge
VIRT number, these mappings don't cause any harm.

For the curious, here are the complete map diff, before and after I click on
the menu:

> 0015a000-0015d000 r-xp 00000000 03:01 65215      
> /usr/lib/pango/1.5.0/modules/pango-hebrew-fc.so
> 0015d000-0015e000 rwxp 00002000 03:01 65215      
> /usr/lib/pango/1.5.0/modules/pango-hebrew-fc.so
< 092df000-09431000 rw-p 092df000 00:00 0 
> 092df000-094ae000 rw-p 092df000 00:00 0 
> b4056000-b40b6000 rw-s 00000000 00:08 19496969   /SYSV00000000 (deleted)
> b40b6000-b4bfe000 r--p 00000000 03:01 426187     /usr/share/icons/hicolor/icon
-theme.cache
> b4bfe000-b6745000 r--p 00000000 03:01 848001     /usr/share/icons/crystalsvg/i
con-theme.cache
> b6745000-b6e9b000 r--p 00000000 03:01 1630568    /usr/share/icons/gnome/icon-t
heme.cache
> b6e9b000-b7c2f000 r--p 00000000 03:01 1026257    /usr/share/icons/Bluecurve/ic
on-theme.cache
> b7c2f000-b7c3d000 r--p 00000000 03:01 2347542    /usr/share/icons/Clearlooks/i
con-theme.cache



-- 
Nadav Har'El                        |      Tuesday, Jan 16 2007, 27 Tevet 5767
[EMAIL PROTECTED]             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |This box was intentionally left blank.
http://nadav.harel.org.il           |

=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to