Xref: utzoo comp.editors:1240 gnu.emacs:2095 comp.unix.wizards:20019 Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!ficc!peter From: peter@ficc.uu.net (Peter da Silva) 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: Date: 5 Jan 90 12:31:07 GMT References: <1558@aber-cs.UUCP> <1025@uc.msc.umn.edu> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 21 > The scheme that was used is called paged buffer gap and it is briefly > mentioned on page 36 of the thesis. The basic idea is that a file is > represented as an array of pages. Each ~1K page is a separate buffer > gap system. That's another technique. With such small buffers, though, you'll lose some on bigger systems. And of course Craig goes on to note... > I contend that in a "modern workstation environment" (e.g., Sun 3/60), > a simple buffer gap method is preferred over both paged buffer gap and > linked line. I leave it as an excercise for the reader to figure out > why. I'm not sure this is a valid conclusion. If 75K is the optimal file size for a buffer-gap solution, how about paged buffer-gap with 75K pages? Or to add a bit of compromise with some of today's brain-dead architectures perhaps 64K pages would work nearly as well. And how does buffer-gap compare with buffer-splitting? You can think of it as a buffer-gap where you don't always need to fill in the gap when you move the insertion point. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ Also or \_.--._/ v "Have you hugged your wolf today?" `-_-'