GNU Emacs, memory usage, releasing

[Jim Cathey]

>The better solution, made relatively easy by the reasonably modular and
>layered structure of GNU emacs, would be to accept The Emacs Cookbook
>recommendation (adopted by Jove and the MicroEmacs/Gnu family of editors) and
>implement a linked list system. I would suggest just reading (or map, on the
>operating systems that allow it) the file to be edited as a large lump of
>virtual address space, then building a linked list of pointers to lines
>therein, and then to allocate modified lines from ageneral purpose arena.
>Informing the OS of the peculiar access patterns would also help, if
>possible.

So long as line-oriented operation preserved the ability of Gnu Emacs
to edit binary files that have no 'lines' at all.  The MicroEmacs we
have here will choke on these (as does vi, ed, see, siv, and all the
other editors we have), and MicroEmacs' line orientation is so badly
implemented that if (at our site) the file is larger than about 50K it
is _faster_ to start emacs on the file than MicroEmacs.  MicroEmacs
starts faster, but it reads files _much_ slower (fgets,malloc,strcpy).

Somebody or other's master's thesis was on buffer styles (I got a copy with
my copy of MINCE a few years ago), and his conclusion was that the gap method
worked best.  That may have been on a machine that wasn't DPV, though.

Moving the gap by, say, 20 characters should affect at most two pages (four,
if you assume it straddles a page boundary on both ends but this is true for
any scheme and may be disregarded).  A block with a line pointer array might
also affect two pages (the block and the buffer array) so I don't offhand
see the advantage.  Jumping about wildly would touch a lot of pages, but the
assumption is that you work a lot in one place.  The gap approach makes it
very quick to _save_ files, so the auto-save feature is unobtrusive.  It would
be absolutely useless if it took 5-10 seconds to rearrange the line-pointer
and block mess to get it into savable form, or write a line at a time.

If realloc can't do the right thing it should be replaced by one that can.
I believe GNU isn't interested in supporting non-GNU machines (read VAX)
to the extent that it corrupts the architecture of the program.  I somewhat
agree with them in that broken environments shouldn't be catered to, but 
repaired instead.

It would be nice if emacs did sbrk- when it could.  In our environment, we
can also release holes in the _middle_ of the heap.  We added an additional
system call for it.  This gets pages out of the swap space, but they'll be
reallocated (and cleared to zero) if you touch in the hole.

We have a limited virtual address space (2M on some machines, 4M on most 
others) so GNU can't edit those really big log files.  I think only elle can
of the editors I've experienced.  I think it uses linked blocks.

GNU Emacs _is_ awfully large, though, but I haven't noticed any machine
eating behavior.  Of course, we have a lot of smaller machines here, so few
use it at once.  Far more noticible is simultaneous compiles.

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc (jimc at isc-br.iscs.com)
! II      CCCCCC !  (509) 927-5757
+----------------+
			"With excitement like this, who is needing enemas?"