Path: utzoo!utgpu!watserv1!watmath!att!rutgers!ucsd!ucbvax!agate!shelby!neon!Kermit.Stanford.EDU!philip
From: philip@Kermit.Stanford.EDU (Philip Machanick)
Newsgroups: comp.sys.mac.system
Subject: Re: RAM Cache
Keywords: best size
Message-ID: <1990Jun5.174114.7515@Neon.Stanford.EDU>
Date: 5 Jun 90 17:41:14 GMT
References: <41628@apple.Apple.COM> <732@usage.csd.unsw.oz.au> <41579@apple.Apple.COM>
Sender: news@Neon.Stanford.EDU (USENET News System)
Reply-To: philip@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 19

In article <41628@apple.Apple.COM>, marc@Apple.COM (Mark Dawson) writes:
> To give you an example, to compile, link, and Res (via MPW 3.1) my MacApp 
> program (on a IIfx), it took 2 HOURS with RAM cache OFF and 20 MINUTES with
> a 1 or 1.5 meg RAM cache.  Note that increasing the cache 512K from 1meg 
> didn't improve the speed any (I'm still investegating what the speed cutoff
> is).
Isn't this perhaps an indication that the traditional compile/link/run/crash
cycle ought to be re-evaluated? It's hard to discuss alternatives without
being accused of starting arguments about "my compiler is better than yours",
but I've often felt the "integrated environment vs powerful tools" argument
misses the point. RAM is relatively cheap, and designing a whole development
system around the premise that it's cheaper to pipe multiple passes through
the file system than to store everything in RAM as far as possible is 1970s
thinking. So is there a better way? I can't believe using a large RAM cache
is the only solution to a performance problem that has at its heart the
overall architecture of the program being run.

Philip Machanick
philip@pescadero.stanford.edu