Mail Archives: opendos/2000/05/01/12:11:52
Hi,
Joseph Morris wrote:
> The problematic task is loading approx 6MB of data into memory from a number
> of files in a directory tree. For development purposes each file can come
> from one of three locations and each must be checked in turn before deciding
> which version of the file to load, since files from some locations can
> override others.
> So there is not only the loading but also checking for existence of files
> (which the profiler claimed was a bottleneck).
> With this in mind, what would be the optimum caching arrangement?
You sure need more cache than 7 MB, but I guess you can try to disable
the write cache and use all options to increase read cache.
Can't you make a trick for version controls (small id files, or file names)
iso reading many big files ?
And for video-editing, you get adviced to use separate HDDs for the apps
and for your files (prefered SCSI).
And use good coolers for your HDD(s) and for the whole box.
So if your problem continues and becomes even worse, I'm afraid that the
ONLY solution is in (expensive) hardware. This really can increase the speed
with 100s of procents.
I've various HDDs and especially the HDD's own cache make big differences
(again, I know IBM has HDD with 4 meg cache, very expensive).
Or use a (SCSI-)raid controller. I don't have any experiences with this, but
I know it's twice as fast, since it uses two disks as they are only one.
And I noticed that not only Logitech mouse drivers, but ALL mouse drivers
(and other TSRs) can slow down your machine too much. Remove what you don't
really need (as always) or try other drivers.
BTW, 64 kB clusters are not possible, because FAT16 can't handle parts above
2 gig (16 kB clusters). Larger clusters cause disk waste, but increase
speed. MS-DOS (Win9x) can cache FAT32 parts, but DR-DOS can't read them at
all.
-- Best regards,
-- YoYo.
-- End of message --
- Raw text -