Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!gvgpsa!treehouse!andyp
From: andyp@treehouse.UUCP (Andy Peterman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: C++/MacApp questions
Message-ID: <558@treehouse.UUCP>
Date: 2 Oct 90 21:53:07 GMT
References: <10594@pt.cs.cmu.edu> <242@farcomp.UUCP> <45290@apple.Apple.COM>
Organization: The Tree House
Lines: 37

In article <45290@apple.Apple.COM> marc@Apple.COM (Mark Dawson) writes:
>..............  Also note that a bigger RAM cache does NOT always speed up
>compiling time--if you've made it too big, it will actually slow it down (when
>it flushes the cache, it has to write that stuff out to the disk--so a big
>cache will have lots of stuff to write out (read:much slower)).  For my work,
>(8mb fx, 4mb MPW partion size) I've found that a 96K is the biggest I can use
>before performance starts to degrade.

I thought I'd check this out since I normally use 1024K cache and do
intensive MPW compiles.  The table below shows the results of compiling
one C module (about 1000 lines) of an application and linking it using
the time results from BuildProgram.  The entire program is about 30,000
lines and generates a 160K application.  Most of the time is spent
linking.  I did these tests on an 8 Meg IIcx with MultiFinder turned off.
The second time shown is a repeat build just after the first, which is 
improved due to the caching action:

Cache Size    Time     2nd Time  (in seconds)

Off            50        ---
32K            33        31
64K            32        29
96K            31        28
128K           31        29
256K           30        27
384K           32        27
512K           32        28
1024K          37        29

From this, it seems that a 256K cache gives the best results.  I've
always been use to using a large cache since it seems to improve
performance for most other tasks on the Mac, but I guess I'm going to
lower it when in MPW.  I sure wish the linker would take more advantage
of available RAM and reduce the disk I/O!

	Andy Peterman
	treehouse!andyp@gvgpsa.gvg.tek.com