Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!rochester!pt.cs.cmu.edu!zog.cs.cmu.edu!tgl From: tgl@zog.cs.cmu.edu.UUCP Newsgroups: comp.sys.mac Subject: Re: Optimal Cache Size? (long) Message-ID: <1021@zog.cs.cmu.edu> Date: Tue, 14-Apr-87 08:41:34 EST Article-I.D.: zog.1021 Posted: Tue Apr 14 08:41:34 1987 Date-Received: Sat, 18-Apr-87 03:06:05 EST References: Reply-To: tgl@zog.cs.cmu.edu (Tom Lane) Distribution: na Organization: Carnegie-Mellon University, CS/RI Lines: 81 Summary: 64K seems to be plenty In (they've got to be kidding :-) rs4u#@ANDREW.CMU.EDU (Richard Siegel) writes: >Is there a cache size that generally works the well with all programs? I have >a Mac Plus, and I've been using a 96K cache, but performance doesn't seem as >nice as it could be... When I first got my Mac+, I ran some experiments with different cache sizes. I've forgotten the details, but I think I measured the time needed to repeatedly launch some program (maybe MacWrite) and return to the Finder. Theoretically, the second time around, some of what you need will be in the cache and thus won't have to be read from disk. I do remember that I found only minimal improvements with cache sizes exceeding 64K; that's the cache size I've used ever since. What I didn't know at the time was that the cache will buffer writes as well as reads (i.e. it isn't "write-through"). So performance improvements can be expected while writing files, not just when reading them. On seeing Siegel's query, I decided to revisit the question. Here's the experiment I designed: 1. Set desired cache size, and reboot to make sure it's in use (cf. April 87 MacUser, pp 143-144). 2. Launch Lightspeed Pascal with a fairly trivial program (one Pascal source file of 139 lines, compiles to 2600 bytes + required libraries). 3. Insert & delete a blank line at the head of the source file, so LSP will think it needs to be recompiled. 4. Hit "Go". This causes LSP to recompile, save the new object code in the "project" file, save the source code (I had Auto-Save on), and start the program. This particular program starts by opening an SFGetFile dialog window. 5. Repeat steps 3 and 4, this time measuring the time from hitting command-G to the appearance of the dialog window. Having compiled once already, all of LSP's code resources are already in memory, so the disk activity here consists of writing the project file, writing the source file, (probably) reading the project file, and reading the disk directory. About two-thirds of the elapsed time seems to be taken up with disk activity, so the compilation time doesn't overshadow the disk I/O. I ran this on a vanilla Mac Plus, System 3.2 (Finder 5.3, not that it should matter), LSP 1.0, 800K HFS internal floppy disk the only mass storage. The results: Cache Time (seconds, measured by wristwatch) OFF 21 - 22 32K 20 - 21 64K 19 - 20 128K 19 192K 19 256K 18.5 512K 18 768K Failed (LSP hasn't enough memory to compile) Curiously, a repeat timing (*third* time through the loop) often took a second or so longer; thus two figures are given. I have no explanation for this behavior. The lack of improvement is striking. One possible explanation is that LSP may somehow empty out the cache when starting and/or stopping the user program. I doubt that this is the story though, since the pattern of disk activity noises seems about the same when the cache is off as when it is on. (In particular, plenty of I/O happens before reaching the point where the user program is started.) Bottom line: I'm still using 64K, and am beginning to wonder if I should just turn the cache off. I offer this story to the net in hopes that someone can cast some light on it. (Think Technologies, are you listening?) I'd also like to hear about similar experiments carried out with other kinds of applications; maybe this is just a peculiarity of LSP. (For what it's worth: I have found out, in other messing around, that this same compile/execute cycle in LSP is sped up significantly by moving the project file to a ramdisk. The source files can stay on real disks, so little work would be lost in the event of a crash.) tom lane ----- ARPA: lane@ZOG.CS.CMU.EDU UUCP: ...!seismo!zog.cs.cmu.edu!lane BITNET: lane%zog.cs.cmu.edu@cmuccvma