Laine Stump writes:
> Actually, isn't this going to be the case with just about any
> application written in an interpreted (either from ASCII text or from
> byte-code) language? 

I had forgotten about perl.  Although thinking about it now, I do
wonder if the ratio of interpreted data and code to cpu-native data
and code is quite as bad for typical perl programs as for emacs.

> The main difference in emacs is that the lisp
> byte-code is stored as a part of the binary (via the weird build-time
> process of loading the binary and byte code files, then generating a
> coredump) whereas a generic perl/tcl/java program will be in a
> separate file from the interpreter binary.

Emacs certainly used to do that.  It was one of the biggest pains in
porting emacs to new OS's.

Seeing how in my example the data space was 2 megs and text was 1 meg,
I have to wonder if that temacs load/dump is still used for much.  In
the old days (late 80's) most of the data was moved into text space
during the load/dump.

One thing that always annoyed me about the default emacs install was
that the install was done with the sticky bit set.  That tended to
chew up quite a bit of ram.  Perhaps now is the time to play with
turning it on???

-wolfgang
-- 
Wolfgang Rupprecht    <wolfgang@wsrcc.com>     http://www.wsrcc.com/wolfgang/
Coming soon: GPS mapping tools for Open Systems. http://www.gnomad-mapping.com/