Mail Archives: opendos/1997/12/16/16:18:02
Lots of small files imply lots of work scanning directories. One thing
is to put the most important directories first in your path, another is
to not have a directory with lots of data files yet only a few
executables in your path (it may be more efficient to have a directory
with batch files containing the exact pathnames early in your path, and
possibly on a RAMDISK).
I have found in the past that setting buffers to something significant,
even with a cache, improves speed. Without a cache it is easy to tell
the problem with anything doing findfirst/findnext (e.g. a directory
listing) when the number of buffers is less that (number of entries in
a directory/16), as soon as you go beyond what is in the buffers there
is a huge amount of disk activity (it seems findnext has to go all the
way through previously-read directory blocks just to get to the next
one). With a cache, even though they should all be cached, it seems
there is still enough system overheads getting previous dir blocks from
RAM to make searching the path for commands take noticeably longer when
there aren't enough buffers. (I should have tried it again to check,
before saying that, but the important thing is that you can often
easily increase high buffers to consume RAM in the HMA that would
otherwise have been left unused after putting bits of the Kernel and
share there - I find I can fit about 22 there without reducing the RAM
for anything else).
Does verify=on only apply to diskettes? I don't trust diskettes, and
since the reason I use them is to carry small-but-important files a
long way, I hate the trip to be wasted, so I agree turning it on is a
good idea despite the performance hit on diskette writes. I find
diskette reads slower under DRDOS/Novell DOS/OpenDOS (haven't tried the
7.02B yet properly, so I'm interested in technical information of the
improvements like the original poster).
If you specify FILESHIGH and there isn't enough RAM up there for all of
them, do the file handles that are used *first* or *last* get put into
the (sometimes faster) conventional memory?
I used to have a driver that provided a combination of Disk cache and
RAMDISK, where partially using the RAM disk would mean more RAM was
lent to the cache. Does anybody know of a RAMDISK (VDISK) that could
be used with NWCACHE to share unused RAM between cache, ram disk and
other programs?
-------------------------------------------------------------------------
Mark Aitchison, \_ Phone: +64 3 364-2947 home 337-1225
Dept of Physics & Astronomy, </ Fax: +64 3 364-2469 or 364-2999
University of Canterbury, /) E-mail: phys169 AT csc DOT canterbury DOT ac DOT nz
Christchurch, NEW ZEALAND. (/' www.phys.canterbury.ac.nz/~physmsa
-------------------------------------------------------------------------
- Raw text -