Mail Archives: djgpp/2000/03/02/12:46:07
On Wed, 1 Mar 2000, Kalum Somaratna aka Grendel wrote:
> > SmartDrv flushes its buffers when a program exits, so it is slower
> > than a RAM disk.
>
> This is the default behaviour of smatrdrv and is there for people who are
> afraid that they might loose data because of write caching etc.
> But if you add the /N option IIRC this will tell smartdrv not to flush the
> write cache when the program exits.
See my followups, they explain why /N is not what you think it is.
> > > And there will be more efficient memory usage as there is no need to
> > > allocate memory as in a ramdisk for the whole tool chain, for how many of
> > > the tools do we actually use?
> >
> > If you have enough memory installed, this is not an issue.
>
> Actually how much should "enough" be?
If you have 64MB or more installed, I don't think you should have
problems with having a large SmartDrv cache and a fairly large RAM
disk.
> GCC itself hogs up a large amount of
> memory and allocationg too much memory for a ramdisk will be
> counterproductive as GCC will start paging to the hard disk.
I have a 10MB cache and a 4MB RAM disk on a 64MB machine, and I have
yet to see GCC paging, even though I mostly invoke it from Emacs,
which itself gobbles upwards of 10MB of memory on a bright day.
Of course, one can come up with a source which would cause GCC to page
with *any* amount of memory. (Just a few days ago someone reported on
the GCC mailing list that a certain code line caused GCC to allocate
500MB of memory.) The question is, how frequently do these
pathological cases happen to warrant changes in system configuration.
Punishing 99.99% of compiles because of the naughty 0.01% is not wise,
IMHO.
> FWIW I find that a 8mb smartdrv with write caching enabled and the /N
> switch works marvels and is far easier to setup than a RAMDISK.
Try adding a 2MB RAM disk on top of that, point TMPDIR to it, and see
the effect.
Setup problem? What setup problems? There are no setup problems ;-).
- Raw text -