🚀 go-pugleaf

In article <21246@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>In article <1987Oct9.001743.14846@gpu.utcs.toronto.edu> mms@gpu.utcs.UUCP (John J. Chew III) writes:
>>I'd like to be able to put my header files on a small ramdisk, as reading
>>them in seems to be the most time-consuming part of my compiles
>
>Why bother? Just crank up the RAM Cache on the control panel and you get
>better than the same effect: the include files that are getting used a lot
>right now, stay in the cache, and you don't have to worry about explicitly
>moving files around.

This certainly does give a nice speed increase, especially if you have
2 Meg or more to run around in.  But I am hesitant to use RAM cache when
I am debugging tricky code that is crashing a lot; I worry about losing
source changes that have not been written from the cache out to disk.  

I asked one of the folks at Think whether LSC was smart enough to
flush the cache before a project is started up from the "Run" command.  He
claimed that this was not the case, and that there was no way that LSC
could tell whether the cache was enabled.  He said that he did not trust
the RAM cache well enough to use it for his own development work.

Now I am wondering: would it be possible to have an item in the "Options"
dialog so that the user could inform LSC that a cache was in use - and
that a flush should be done before running a project?  Or maybe a future
version of LSC will be smart enough to implement its own caching mechanism,
or other memory management schemes that take greater advantage of large
memory environments.  ("criminies," they must be saying at Think, "ain't it 
fast enough?).

I also remember seeing a description of a cache flush FKEY some time ago. 
Would that do the trick?  If so, could someone mail me a copy?
-- 
Julian Vrieslander    (607) 255-3594
Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853    
UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!eacj
ARPA: eacj@tcgould.tn.cornell.edu     BITNET: eacj@CRNLTHRY