Xref: utzoo comp.editors:1250 gnu.emacs:2108 comp.unix.wizards:20056
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!uc!uh!fin
From: fin@uh.msc.umn.edu (Craig Finseth)
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: <1060@uc.msc.umn.edu>
Date: 8 Jan 90 16:48:15 GMT
References: <1558@aber-cs.UUCP> <1025@uc.msc.umn.edu> <SN_87Eggpc2@ficc.uu.net>
Sender: news@uc.msc.umn.edu
Reply-To: fin@uh.UUCP (Craig Finseth)
Organization: Minnesota Supercomputer Center, Minneapolis, MN
Lines: 21

In article <SN_87Eggpc2@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>> 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.

Where did this "75K" figure come from?  It wasn't mentioned by me.  It
would be a very unusual constant to remain constant over a wide range
of architectures, speeds, memory sizes, and other performance-related
figures.

In particular, I have had no trouble editing multi-megabyte files in
GNU Emacs on a Sun 3/280 w/8 MBytes of memory.

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