[3708] in Athena Bugs
color xterm a memory hog
daemon@ATHENA.MIT.EDU (Joe Harrington)
Wed Nov 22 16:08:32 1989
Date: Wed, 22 Nov 89 16:07:51 EST
From: Joe Harrington <jh@SOL.MIT.EDU>
To: bugs@ATHENA.MIT.EDU, tytso@ATHENA.MIT.EDU
Cc: jh@ATHENA.MIT.EDU
Reply-To: jh@ATHENA.MIT.EDU
As some readers of this list are painfully aware, our lab's GPX's have
had many memory problems running color X11R3 under 6.3B. I've traced
the problem somewhat, with Ted T'so's help. Using pstat -s, I find
that xterm takes up a LOT more space on color machines than on
monochrome. Twice as much space, in fact, as emacs. The method I
used was to do a pstat -s before, during, and after starting and
exiting the specific program listed below, and differencing the free
space. I did it several times for each client. The machine was
otherwise unused.
client memory (meg)
emacs mono 0.5
emacs color 0.6
xterm mono 0.4
xterm color 1.3
X11R3 server 1.1 (this is the server with Tim Shepard's mods, and
run -bs -su)
These stats indicate (to me anyway) that xterm's color code is
horribly inefficient, and could be vastly improved. And then our
machines wouldn't crash so often!
Also, the failure mode of the Xqdss server is poor. If it runs out of
memory, it just crashes. Hasn't anyone ever heard of checking the
return value of malloc()? (down Joe, it's Thanksgiving...)(sorry...)
--jh--
