Xref: utzoo comp.editors:1241 gnu.emacs:2096 comp.unix.wizards:20021
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!shelby!neon!neon!gumby
From: gumby@Gang-of-Four.Stanford.EDU (David Vinayak Wallace)
Newsgroups: comp.editors,gnu.emacs,comp.unix.wizards
Subject: Re: GNU Emacs, memory usage, releasing
Message-ID: <GUMBY.90Jan6045022@Gang-of-Four.Stanford.EDU>
Date: 6 Jan 90 12:50:22 GMT
References: <1558@aber-cs.UUCP> <129799@sun.Eng.Sun.COM> <50359@bbn.COM>
	<IN_S4Eggpc2@ficc.uu.net>
Sender: news@Neon.Stanford.EDU (USENET News System)
Organization: Computer Science Department, Stanford University
Lines: 56
In-Reply-To: peter@ficc.uu.net's message of 5 Jan 90 12:21:46 GMT


   Date: 5 Jan 90 12:21:46 GMT
   From: peter@ficc.uu.net (Peter da Silva)

   There seems to be an assumption here that the only possible methods
   are buffer gap and a linked list of lines. What about a linked list
   of larger blocks?[...]I can't remember the editor involved,
   unfortunately, nor the algorithm for coalescing blocks.

TEdit, the wysiwyg editor for Interlisp-D used this technique.  It has
several problems, including the difficulty of implementing search
cheaply and its memory footprint (loss of locality).  If your aim is
to reduce copying this will help, but you'll end up with chunks
scattered through memory, which could in a pessimal case result in
significantly worse paging performance.  As was already pointed out,
because of the way humans edit text, the advantage of having lots of
little gaps isn't that great since people tend to edit in a small
number of places at a time.  Many also use search as the primary means
of moving the cursor.  On the other hand the main use of this
technique is to help integrate the redisplay datastructures with the
buffer data.  There are other, cheaper ways to do this, as have been
previously described.

   And of course reading and writing files as nearly as easy as with the buffer-gap
   technique.

Actually it won't be, since you can't write the buffer in (at most)
two block writes and read it in one.  Instead you have either to
follow the block chains (when writing) or construct them (when reading).

	      Given an appropriate system architecture, such as Mach, you could
   even fault your blocks in from the file!

Mach doesn't do object (structure) paging to my knowledge.  On the
other hand, with a linear structure as with the gap the pager already
does this for you.

For large arrays like this it would be better to improve the pager.
Here are some suggestions (some are supposed to appear in 4.4, I
think):
1> Allow the program to tell the pager which pages are no longer
    needed (ie set the access time to "long ago").
2> Allow the program to change the page-ahead factor for blocks of
   pages, for cases when you know you'll want to do sequential access.
3> Allow the program to change the page mapping (think of it as mmap
   to your own addess space).  Then when you open a gap, you always
   copy at most one page; you just split the page on which the gap
   apears into two and translate the pages above or below by one.

You've already got paging hardware; why not use it to your advantage?

regards,
d

Now if you want OS mods to improve interactive performance, adding
ECHOIN would be a good place to start...