[Rule-list] Suggestion for modifying XFree86 and Tiny X
Bill Crawford
rule at billemon.org.uk
Thu Mar 21 06:57:00 EET 2002
On Wed, 20 Mar 2002, Eugene Wong wrote:
> Thanks for replying and explaining the above information. Everything that is
> above, perfectly deals with my concerns. It all says to me, that yes,
> XFree86 is still efficient. I really appreciate it. Also, thank you for the
> "killall" and "kill" info. I never knew that before.
>
> As disappointed as I am to see that my ideas won't come into fruition, I am
> glad to realize that you saved everybody a lot of time! :-)
I'm sorry if my reply was a little brusque.
Having worked with some very old machines at home for a long time, I
do have a lot of sympathy for anyone else who has to use older systems
with modern software ... I was "lucky" enough to be able to build a
newer system with part of a redundancy payment a couple of jobs back,
so I don't worry so much now for myself (although apps like Nautilus
and Evolution can make even my Athlon feel like a 486 at times :o)
I'd like to see perhaps "lighter" versions of some applications, for
example everyone thinks of Netscape as a huge bloated thing but NS 3.x
was (especially compared to today's browsers) quite lightweight and I
still remember it with fondness for its mail and news interface. But
I really don't want to try rewriting a browser; I've done very little
GUI stuff since my brief and painful flirtation with Windows, apart
from an etch-a-sketch in Xlib and drawing a Union Jack in a window.
For some "hard figures" ...
4:21am up 6 days, 22:15, 16 users, load average: 0.00, 0.00, 0.03
89 processes: 88 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.1% user, 0.1% system, 0.0% nice, 99.6% idle
Mem: 255512K av, 247784K used, 7728K free, 0K shrd, 3924K buff
Swap: 2101060K av, 80088K used, 2020972K free 47424K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
22765 root 10 0 115M 27M 11076 S 0.0 10.8 2:58 X
1103 xfs 9 0 8492 3384 2992 S 0.0 1.3 5:23 xfs
22804 bill 9 0 3956 3092 2560 S 0.0 1.2 0:02 panel
22819 bill 9 0 3168 2616 2176 S 0.0 1.0 0:01 tasklist_applet
22821 bill 9 0 3120 2520 2184 S 0.0 0.9 0:01 deskguide_apple
24395 bill 9 0 2484 2484 1900 S 0.0 0.9 0:00 xterm
22768 bill 9 0 2932 2188 2188 S 0.0 0.8 0:00 gnome-session
742 ntp 9 0 1876 1876 1812 S 0.0 0.7 0:00 ntpd
23365 bill 9 0 3712 1816 1556 S 0.0 0.7 0:10 xterm
22799 bill 9 0 2044 1780 1352 S 0.0 0.6 0:02 wmaker
22929 bill 9 0 2356 1644 1644 S 0.0 0.6 0:00 xterm
23015 bill 9 0 2224 1644 1644 S 0.0 0.6 0:00 xterm
22963 bill 9 0 2480 1640 1640 S 0.0 0.6 0:00 xterm
23049 root 9 0 2008 1632 1632 S 0.0 0.6 0:00 xterm
23251 bill 9 0 2228 1468 1468 S 0.0 0.5 0:00 xterm
22862 bill 9 0 2024 1456 1456 S 0.0 0.5 0:00 xterm
22876 bill 9 0 2016 1456 1456 S 0.0 0.5 0:00 xterm
23198 bill 9 0 2016 1456 1456 S 0.0 0.5 0:00 xterm
22825 bill 9 0 2056 1452 1452 S 0.0 0.5 0:00 xterm
24397 bill 9 0 1452 1452 1012 S 0.0 0.5 0:00 bash
23095 bill 9 0 1992 1448 1448 S 0.0 0.5 0:00 xterm
22881 bill 9 0 1992 1444 1444 S 0.0 0.5 0:00 xterm
23164 bill 9 0 1980 1436 1436 S 0.0 0.5 0:00 xterm
23130 bill 9 0 1976 1432 1432 S 0.0 0.5 0:00 xterm
22806 bill 9 0 1484 1316 1136 S 0.0 0.5 0:02 xscreensaver
Most of the memory usage figure for X is down to mappings for the
graphics card (32MB, plus AGP aperture mapping for DRI). The real
hogs are the font server (understandable as I have several different
fonts in use) and the GNOME panel; and Netscape, when I run it, will
happily bloat up to 60+ MB footprint (running that on a 16 meg box
was fun). So what's really needed is to trim the footprint of many
of the applications.
In fairness to GNOME, the use of lots of shared libraries does save
a lot of memory once you have more than one app running; in fact one
of the biggest actual users of memory I find is xterm sessions, which
because I set the scrollback size high (and use large windows) are a
meg each (the SHARE column shows that most of the memory used is the
glibc and X libraries plus the executable itself).
So the biggest savings (sadly) will be:
· low resolution / depth displays - reduces X server memory size
· avoiding TrueType and other scalable fonts
· not using too many different fonts
· don't open too many xterms (the scrollback is a killer - e.g. ten
xterm windows, 96x32 with 4096 lines scrollback = 8 megbytes (worse
if you use utf8 / unicode font, i.e. double that).
· a lightweight browser - mozilla is not the way to go:
24850 bill 11 0 21160 20M 12260 S 0.1 8.2 0:02 mozilla-bin
- that's with just the default RH index page loaded, no browsing.
Eight MB used already, and I just launched it. Even galeon, the
much touted lighter alternative to mozilla, uses around 5 MB over
the shared libs and executable, total footprint ~18MB
24877 bill 11 0 18536 18M 13120 S 0.0 7.2 0:01 galeon-bin
· text-based MUA - pine or mutt will have to be the default mail
client. Unless anyone can resurrect Netscape 3 :o)
· avoid graphical screensavers. No kidding, xlock used to use more
memory than almost everything except Netscape. xscreensaver buys
you a bit of headroom because it runs the graphics stuff as separate
processes and therefore reclaims memory after each one finishes; but
you're still looking at a huge resident set.
· no background images. A plain colour background can save you up
to 3 MB for 1024x768x24 display, nearly 1 MB for 8 bit depth. On
a low memory machine this saves a lot of swapping when you close a
window and the server has to redraw the background :o)
_______________________________________________
Rule-list mailing list
Rule-list at mail.freesoftware.fsf.org
http://mail.freesoftware.fsf.org/mailman/listinfo/rule-list
This full static mirror of the Run Up to Date Linux Everywhere Project mailing list, originally hosted at http://lists.hellug.gr/mailman/listinfo/rule-list, is kept online by Free Software popularizer, researcher and trainer Marco Fioretti. To know how you can support this archive, and Marco's work in general, please click here