Mail Archives: opendos/1997/12/23/08:22:56
X-Comment-To: Mr M S Aitchison
Hi!
17-δΕΛ-97 10:13 physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison) wrote to opendos AT delorie DOT com:
> 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).
This is one reason why me liked "ln" ideology from UNIX'es. BTW, my
\BAT directory contains some .bat files for reducing path in such way:
______________O\_/_________________________________\_/O______________
@if not %edit%.==. %edit%\word\word %1 %2 %3 %4 %5 %6 %7 %8 %9
@if %edit%.==. c:\edit\word\word %1 %2 %3 %4 %5 %6 %7 %8 %9
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
@c:\nd\nc\nc
_____________________________________________________________________
O/~\ /~\O
etc.
> I have found in the past that setting buffers to something significant,
> even with a cache, improves speed.
Yes, this is true. So I don't understand, why M$ recomends reduce
byffers to 0 when cache installed. B-\ Although itself M$ generates too many
files in some directories (\WINDOWS, \WINDOWS\SYSTEM)... B-/
> 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.
Look correct.
[...]
> 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).
Look at PU_1700's PU_WRCFD, which replaces verify for diskettes (and
only for diskettes). Verify is not reliable, because not check how data
written in reallity, so not too few diskettes after Verify not works
correctly - but, PU_WRCFD after write read data back and compares with
source. In practice this slowdown twice, but if data written - they written
more reliable.
[...]
> 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?
Afaik, such cache+ramdrive combination exist - look at combo.sys
(although I itself not try this).
- Raw text -