Xref: utzoo comp.editors:1254 gnu.emacs:2115 comp.unix.wizards:20069 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!texsun!texbell!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: 8 Jan 90 22:07:52 GMT References: <1558@aber-cs.UUCP> <1025@uc.msc.umn.edu> <1060@uc.msc.umn.edu> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 25 > >> 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 > Where did this "75K" figure come from? I honestly don't remember. It was mentioned by someone in this forum. I do think, though, that for any given system there is such an optimal size. It may be that on your workstation that size is measured in megabytes... on others it may be a few K. I wonder how it feels on a NeXT that's paging over the network or onto the OD? > >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. > In particular, I have had no trouble editing multi-megabyte files in > GNU Emacs on a Sun 3/280 w/8 MBytes of memory. Having "no trouble" with something doesn't mean you have the optimal solution. Just that you have *a* solution. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ Also or \_.--._/ v "Have you hugged your wolf today?" `-_-'