Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!eacj From: eacj@batcomputer.tn.cornell.edu (Julian Vrieslander) Newsgroups: comp.sys.mac Subject: Re: Possible LSC improvements Message-ID: <2638@batcomputer.tn.cornell.edu> Date: Wed, 31-Dec-69 18:59:59 EDT Article-I.D.: batcompu.2638 Posted: Wed Dec 31 18:59:59 1969 Date-Received: Wed, 14-Oct-87 01:18:47 EDT References: <2071@sfsup.UUCP| <170026@acf3.NYU.EDU> <2936@husc6.UUCP> <1987Oct9.001743.14846@gpu.utcs.toronto.edu> <21246@ucbvax.BERKELEY.EDU> Reply-To: eacj@tcgould.tn.cornell.edu (Julian Vrieslander) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 36 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