Article View: comp.sys.ibm.pc.programmer
Article #1445Re: Editing Huge Files, and strategies therein
From: Ralf.Brown
Date: Sat, 03 Mar 1990 11:24
Date: Sat, 03 Mar 1990 11:24
53 lines
3262 bytes
3262 bytes
In article <77832@tut.cis.ohio-state.edu>, schanck@harmonica.cis.ohio-state.edu (Christopher Schanck) wrote:
}With the recent discussion on comp.sys.ibm.pc on which editors will
}handle files larger than memory, no one has discussed any of the
}strategies used by these editors. Blackbeard's, Norton's, Sprint,
}Multimate, Brief, and others were mentioned as editors which could do
}this.
}
}Could somebody enlighten me as to how this is accomplished in some of
}these cases, or a general strategy for doing so for an editor? I have
}not a lot of desire to reinvent the wheel, or reinvent it
}inefficiently, so I would appreciate some info on the topic itself, or
}on where I could find such info.
From my poking around in Sprint's swap file, I was able to determine the
following:
the swap file is divided into 1K pages, which may hold up to 1018
bytes of data (six bytes are used for "next" and "prev" pointers
and a count of the actual amount of data stored in the page)
each file is stored as a doubly-linked circular list, whose head is
in a special control page (which themselves are in a d-l circular
list whose head is the first page in the swap file)
any memory available above the 220K needed for the Sprint executable
and fixed scratch space is used as a cache for the swap file
insertion of new text can cause the addition of a new page containing
only a few bytes into the middle of the file's linked list; thus,
it is possible for the file to use up considerably more space in
the swap file than when stored as plain text. In my experience, the
swap file tends to grow by 20-25% over the course of editing a file
(even after accounting for the file's growth).
deletion of text presumably only changes the page(s) on which the
deleted text resided, leaving unused space at the end of the page.
Unless BlackBeard has changed its strategy since v7.39, it edits files larger
than the 50K edit buffer by reading in a chunk at a time and rewriting the
entire file from that point on when you move out of the current section of
the file. Gets rather tedious when editing the start of a large file
(particularly since BB shares the edit buffer with its internal line pointers--
editing a 25000-line file means that a "current section" is less than 1K in
size!)
--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask
ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46
"How to Prove It" by Dana Angluin Disclaimer? I claimed something?
16. proof by cosmology:
The negation of the proposition is unimaginable or meaningless. Popular
for proofs of the existence of God.
Technical Details
Message-ID:
<25efb778@ralf>Path:
arc1-ca.pugleaf.net!utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDUShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU From: Ralf.Brown@B.GP.CS.CMU.EDU Newsgroups: comp.sys.ibm.pc.programmer Subject: Re: Editing Huge Files, and strategies therein Message-ID: <25efb778@ralf> Date: 3 Mar 90 11:24:24 GMT Sender: ralf@b.gp.cs.cmu.edu Organization: Carnegie Mellon University School of Computer Science Lines: 53 In-Reply-To: <77832@tut.cis.ohio-state.edu>