Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!psuvax1!rutgers!mcnc!decvax.dec.com!deccrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: Date: 26 Sep 90 19:24:21 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <14646@cbmvax.commodore.com> <14669@cbmvax.commodore.com> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 48 In-Reply-To: andy@cbmvax.commodore.com's message of 26 Sep 90 16:52:06 GMT In article <14669@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: Just a couple: Most gap editors I'm familiar with have two places where the user experiences speed hits 1) when the editor is spooling text off to disk The shouldn't be a problem. In fact, a buffer gap should be faster than the linked list of lines that mg currently use, as you replace one write per line with two per buffer. That's one of the reasons for wanting to make the change. Now, if you're talking about paging unused pages to disk, and new pages back - that's a different problem, and one I haven't looked into. 2) when the gap is being shifted in a large file That's the critical problem. That's why I like the idea of one gap per buffer, with middlin-sized buffers (4 to 16K, say). That way, the worst thing to have to move is a chunk of text of that size. editing files no larger than 32K, for instance, because otherwise the pauses as they scrolled and edited drove them crazy. Stock buffer gap shouldn't have a problem scrolling (you don't move the gap unless edit text, so scrolling doesn't involve any buffer movement). If it's paging, then there might be a problem. And, the logical place to use as a temporary directory is :t if one doesn't exist, create it. Edit, which can edit files larger than memory available uses a temp file is :t for this purpose. Is that on the device the file is on, or on the device the text editor was started from? And it's sort of silly if you that device winds up being ram:. Likewise, you have to deal with being able to write on that file. Since mg isn't part of a commercial product, I'm tempted to make this feature something you have to enable at compile time, and if it's on, allow the user to give a file name for the disk buffer file. Thanx,