Xref: utzoo comp.unix.wizards:19987 comp.emacs:7518
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!ccncsu!ncr-fc!chuckp
From: chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips)
Newsgroups: comp.unix.wizards,comp.emacs
Subject: Re: GNU Emacs, memory usage, releasing, sequential access, etc
Message-ID: <CHUCKP.90Jan3172133@halley.ncr-fc.FtCollins.NCR.com>
Date: 4 Jan 90 00:21:33 GMT
References: <1558@aber-cs.UUCP> <129799@sun.Eng.Sun.COM>
	<PCG.90Jan3170738@thor.cs.aber.ac.uk>
Sender: news@ncr-fc.FtCollins.NCR.COM
Organization: NCR Microelectronics, Ft. Collins, CO
Lines: 27
In-reply-to: pcg@thor.cs.aber.ac.uk's message of 3 Jan 90 17:07:38 GMT

>>   In article <129799@sun.Eng.Sun.COM> jpayne%flam@Sun.COM (Jonathan
>>   Payne) writes:
>>      I thought paging algorithms were geared towards sequential access,

In article <PCG.90Jan3170738@thor.cs.aber.ac.uk> pcg@thor.cs.aber.ac.uk (Piercarlo Grandi) replies:
>   Most paging algorithms implement some approximation of LRU; LRU is *guaranteed*
>   to trash on sequential access.

Nit: _Freeing_ of disk buffers/pages/etc is typically LRU.  However,
many OS's (e.g. UNIX, VMS "clusters", some of the newer disk controller
_hardware_) also read ahead, which benefits sequential reading
algorithms.  With the BSD file system's clustering by cylinder groups
combined with write-cacheing, sequential writing also benefits.

Thus, while sequential access is slower than no access at all, it's
often _much_ faster than random access.  (HINT: e.g. typical lisp memory
allocation) If you want to see what _really_ slows GNU emacs, type
"C-h a <newline>" and write your reply (in another window) while you
wait for a response.

BTW, I'm leaning toward the buffer gap approach since reading Jonathan
Payne's lucid explanation in comp.editors and comp.emacs.  If you
haven't read it, read it.

#include <std/disclaimer.h>
--
	   Chuck Phillips -- chuckp%bach.ncr-fc.FtCollins.NCR.COM