Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!karazm.math.uh.edu!jet
From: jet@karazm.math.uh.edu (J. Eric Townsend)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Files larger than available memory.
Message-ID: <1990Sep23.174736.16118@lavaca.uh.edu>
Date: 23 Sep 90 17:47:36 GMT
References: <924@ucsvc.ucs.unimelb.edu.au>
Sender: nntppost@lavaca.uh.edu (NNTP Posting Service)
Organization: University of Houston -- Department of Mathematics
Lines: 32




In article <924@ucsvc.ucs.unimelb.edu.au> U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes:
>the discussion re: Virtual Memory/MMU/Protection reminds me of a tangentially
>related issue.  Some criticism of Amiga software (such as word processors) is
>related to the inability to deal with files/data larger than available memory.

What a coinkadink.  A friend of mine is taking a graduate software
engineering class where the project is to (tah-dah) write a text editor
that can deal with files large than available memory (be it virtual or not).
Well, I don't know if they're going to "write" it or not, it *is*
a software engineering class.

It can be done.  It's somewhat bizarre, but it can be done.  Essentially,
you keep track of the changes to the file.  You change the file whenever
you reach one of a set of conditions:
-- size of changes > some default size
-- user is not doing anything (cycle stealing, of a sort :-)
-- user goes forward or backwards in the file some distance > x

The "problem" here is that disk speed affects text scrolling and searching
speed.  If you "^F" (page forward in vi), then the next page has to
be read from disk and then updated from the in-memory list of changes
to that page (if any changes exist).

Any questions?
--
J. Eric Townsend -- University of Houston Dept. of Mathematics (713) 749-2120
Internet: jet@uh.edu
Bitnet: jet@UHOU
Skate UNIX(r)