Article View: comp.sys.amiga.tech
Article #5574Re: Files larger than available memory.
From: Matthew Dillon
Date: Tue, 02 Oct 1990 14:07
Date: Tue, 02 Oct 1990 14:07
48 lines
2231 bytes
2231 bytes
I've always envisioned a scheme like this:
char **Lines;
long **Storage;
long NumLines;
long MaxLines;
Basically, Lines points to an array of pointers to each line in the
file. NumLines specifies the number of lines in the file and MaxLines
specifies the maximum number of entries in the Lines & Storage arrays
that have been allocated (determines when you have to reallocate Lines
due to extending past the MaxLines limit). Storage points to the
file position in either the original file or a scratch file.
Unmodified line, line not in memory
Lines[i] = NULL;
Storage[i] = seek-position-in-original-file
Modified line, line not in memory
Lines[i] = NULL;
Storage[i] = 0x80000000 | seek-position-in-scratch-file
Unmodified line, line in memory
Lines[i] = <ptr-to-memory>
Storage[i] = seek-position-in-original-file
Modified line, line in memory
Lines[i] = <ptr-to-memory>
Storage[i] = 0x80000000 | seek-position-in-scratch-file
In anycase, all that would be required to remain in main memory is
NumLines * 8 bytes. You also get random access out of this scheme.
Additionally, you could implement a locking system (lock line in memory)
internally to make editor functions more efficient.
The scratch file would slowly fill up with changes and, upon reaching
a certain size, would be 'packed' by creating a new scratch file,
copying pertainent entries, and deleting the old.
-Matt
--
Matthew Dillon dillon@Overload.Berkeley.CA.US
891 Regal Rd. uunet.uu.net!overload!dillon
Berkeley, Ca. 94708
USA
Technical Details
Message-ID:
<dillon.6310@overload.Berkeley.CA.US>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillonReferences:
<924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <14646@cbmvax.commodore.com> <MWM.90Sep25180852@raven.pa.dec.com> <1089@ucsvc.ucs.unimelb.edu.au> <523@public.BTR.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: <dillon.6310@overload.Berkeley.CA.US> Date: 2 Oct 90 14:07:14 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <14646@cbmvax.commodore.com> <MWM.90Sep25180852@raven.pa.dec.com> <1089@ucsvc.ucs.unimelb.edu.au> <523@public.BTR.COM> Lines: 48