Date:	Thu, 2 Jun 94 14:24:28 -0600
From:	jan kok <kok AT CS DOT ColoState DOT EDU>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	ramdisk and disk cache (was: Boca SVGAX2 with Cirrus CL-GD542X?)

sasbnb AT unx DOT sas DOT com:
>> By the way, I just thought of a third. I have a monster ram disk, and I
>> would like to put the compiler, linker, libraries, etc there. Is anyone
>> familiar enough with the gcc system setup to tell me exactly which files
>> I would have to copy and which paths/environmental variables I would
>> have to alter to avoid using my hard drive at all?

DJ:
>It's better to switch to a monster disk cache and let *it* worry about
>what you're using most often.  I reserve about 1-2M for ramdisk for
>TMPDIR temp files that gcc generates, and give the rest to the cache.

I find that keeping demacs in ramdisk lets it consistently start up in
one second instead of two or three, which I feel is a noticable improvement.
Putting the compiler, etc. in ramdisk might save a second or so, but you
probably won't notice it since a compile is apt to take many seconds anyway.
If you do a make, the compiler will stay cached from one compile
to the next, if you have a (sufficiently large) disk cache.

Sometimes I put temp files on the ramdisk, sometimes not.  I don't recall
if I've ever timed the difference, but it's never been enough to "feel".
I would think that the disk cache would be as fast as ramdisk for temp files.

Non-huge applications load so fast from disk that it's not worth worrying
about.  For example, the assembler a86 can load, read a couple hundred
lines of source, and produce object, symbol table and listing files
in a *small* fraction of a second.

So my recommendation is to put *large*, *interactive*, *often-used* programs
on ramdisk, and let your disk cache take care of the rest.

(I use SMARTDRV from Windows 3.1 as my disk cache, VDISK from DR-DOS 6.0
as my ramdisk, and have a garden variety IDE disk).

- Jan

- Raw text -