Xref: utzoo comp.editors:1227 gnu.emacs:2081 comp.unix.wizards:19996
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!decwrl!sgi!calcite!vjs
From: vjs@calcite.UUCP (Vernon Schryver)
Newsgroups: comp.editors,gnu.emacs,comp.unix.wizards
Subject: Re: GNU Emacs, memory usage, releasing
Keywords: GNU emacs malloc memory working set gap editor
Message-ID: <81@calcite.UUCP>
Date: 4 Jan 90 17:40:04 GMT
References: <1558@aber-cs.UUCP> <1025@uc.msc.umn.edu>
Organization: Rhyolite Software, Mountain View, CA
Lines: 32

In article <1025@uc.msc.umn.edu>, fin@uh.msc.umn.edu (Craig Finseth) writes:
> ...  Each ~1K page is a separate buffer
> gap system.  This representation was very efficient for the
> environment, especially as it formed a natural basis for the paged
> virtual memory environment required to edit files larger than will fit
> in memory.
> ...
> Craig A. Finseth			fin@msc.umn.edu [CAF13]
> Minnesota Supercomputer Center, Inc.	+1 612 624 3375

An editor called "QED" by Peter Deutch (sp?) of Project Genie at Berkeley
used this technique on one of the first paged virtual memory systems, the
SDS-940 (later XDS-940).  The 940 was one of the intellectual parents of
UNIX in general, and I've been told that ed is in some important sense a
descendent of QED.

By making the buffer size match the system page size, by keeping a
modest amount of free space in each buffer, using your "gap method" within a
buffer, linking buffers together using external links, and possibly doing
manual/explicit paging to secondary storage (scratch files), searches were
fast, memory management was not hard, and so on.  It is a nice combination.

I used this technique in a commercial 4.2BSD based, WYSIWYG, multi-window,
bit-mapped, extensible, object oriented, "integrated" (with graphics,
spread sheet, and DMB) text system with perportional Adobe fonts for a
competator and predecessor of Interleaf.  I thought overall result, given
mid-80's hardware, was fast and powerful.  I must note not only that I no
longer work for that company, but it is essentially out of business.


Vernon Schryver
vjs@calcite.uucp    ...{pyramid,sgi}!calcite!vjs