rs4u#@ANDREW.CMU.EDU.UUCP (04/13/87)
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...
--Rich
Richard M. Siegel
Materials Instrumentation Characterization Section
Mail Stop 231
NASA/Langley Research Center
Hampton, Virginia 23665
(804) 865-3036
Arpanet: rs4u@andrew.cmu.edu
Uucp: {your fave gateway}!seismo!andrew.cmu.edu!rs4u
Disclaimer? I don't even KNOW 'er!tgl@zog.cs.cmu.edu.UUCP (04/14/87)
In <MS.V3.18.rs4u.80020be4.lamar.sun3.2010.10@andrew.cmu.edu> (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
myers@uwmacc.UUCP (Jeff Myers) (04/14/87)
> 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... > Richard M. Siegel That's a good size. I typically use a 96K cache and a 400K Ramdisk with system files. The results are especially pleasing during file transfers and using database software. y in ng,
munson@ernie.Berkeley.EDU.UUCP (04/17/87)
Because I am not a Mac program developer, my needs from the disk cache may be different than those of many people on the net. My Mac is mostly used for terminal emulation, file transfer, games, word processing, and a little spreadsheet work. I keep my disk cache at either 256K or 384K and find that it makes a BIG difference. For example: 1) The first launch of Red Ryder 9.2 takes about 10 seconds. The second launch takes about half that and has audibly less disk access. 2) Without the cache, Excel and Word 1.05 have many more small delays when I make them use less common or more "compute-heavy" features. With the cache, you get the standard caching effect. That is, the first time a new features is used, the disk is accessed. Repeated uses of the feature do not require a disk access. I have no idea why LightSpeed Pascal doesn't show much improvement with the cache, but I sure like having it. Ethan Munson munson@ernie.berkeley.edu ucbvax!ernie!munson