Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!uc!uh!fin
From: fin@uh.msc.umn.edu (Craig Finseth)
Newsgroups: comp.editors
Subject: Re: What is buffer gap you ask?
Message-ID: <1033@uc.msc.umn.edu>
Date: 4 Jan 90 17:28:29 GMT
References: <129846@sun.Eng.Sun.COM> <62420008@hpl-opus.HP.COM>
Sender: news@uc.msc.umn.edu
Reply-To: fin@uh.UUCP (Craig Finseth)
Organization: Minnesota Supercomputer Center, Minneapolis, MN
Lines: 56

In article <62420008@hpl-opus.HP.COM> walker@hpl-opus.HP.COM (Rick Walker) writes:
	...
	I was also convinced that the buffer gap was the best way to write an
	editor until I read "RED, a better C screen editor" by Edward K. Ream 
	in Dr. Dobbs Journal, Number 81, July 1983.
	...

As I mentioned in my previous posting, this technique was described in
my 1980 thesis as "paged buffer gap."  It was first implemented in a
floppy-based CP/M environment, and was well-suited to that
environment.  This technique essentially allows you to create a
virtual memory environment in software.

However, it is a (not universally accepted) software axiom that an
application-writer has better things to do than re-implement the
operating system.  CP/M did not offer any paged virtual memory
support.  Hence we did not re-implement anything.  However, a "typical
workstation environment" (e.g., Sun) offers the virtual memory support
in hardware.

For those of you who do not accept the aforementioned axiom, I contend
that the paged buffer gap scheme performs worse than a standard buffer
gap scheme for the following reasons:

- First, all sequential search operations require that the data being
searched through be in memory, at least momentarily.  (Search strings
are in general much smaller than page or line sizes, so sub-linear
searches do not save a significant number of paging operations.)
Standard buffer gap schemes offer the most efficient use of both
memory and paging hardware.

- Next, extra overhead is incurred during file reads, which are relatively
common.  (The same overhead is incurred during writes, but they are
relatively rare.)

- Additionally, paged buffer gap is more complex to implement than
standard buffer gap (personal experience: I've done both).

- Finally, Modern hardware is fast enough that large blocks of memory
can be moved quickly and efficiently.  In particular, a recent message
contained timing data showing that an 80K byte buffer move was not a
significant problem.  Hence, paged buffer gap is a solution in search
of a problem.

Remember that the gap only moves when both of these conditions are met:

- An insert or delete (but not replace) operation is performed.

- The gap is not at the place where the operation is to be performed.

The gap never moves (and pages are never modified) when data is only
being read.


Craig A. Finseth			fin@msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	+1 612 624 3375