Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!decwrl!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: 2 Oct 90 20:00:58 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> <483@public.BTR.CO Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 36 In-Reply-To: eeh@public.BTR.COM's message of 27 Sep 90 17:00:55 GMT In article <483@public.BTR.COM> eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) writes: The logical place to put the temporary file is in t: (maybe that's what Andy meant) so you can assign the temporary directory wherever you want: RAM: for speed, or a HD partition for size. Let me see if I've got this straight: the stuff that the editor pages out to disk because there's not enough ram, you want to put in RAM: for speed? Methinks there's a problem here. If nothing else, it'd probably take less memory and be faster just to leave the information paged in. 1) Allow the user to (optionally) specify the number of buffers to use when launching mg. Sorry, the number of buffers is unlimited, and will stay that way. Besides which, a single buffer can grow arbitrarily large. Allowing for a fixed amount of memory to be used might (just might) be possible, but would either require 1) pre-allocating that much memory, which isn't acceptable for editing small files, or 2) keeping a running total of how much memory was allocated, which is liable to add to much overhead. Since the point of paging to disk is to allow editing of files larger than memory, adding other strange constraints seems counterintuitive. 2) Provide a "flush out all buffers to disk" command in mg to free up memory just before launching a memory hog application. Not possible, mostly for portability reasons.