Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!pozar
From: pozar@hoptoad.uucp (Tim Pozar)
Newsgroups: comp.sys.ibm.pc
Subject: Re: DOS is fast? (Was Re: Why unix doesn't catch on)
Message-ID: <7222@hoptoad.uucp>
Date: 9 May 89 16:27:04 GMT
References: <7632@phoenix.Princeton.EDU> <256@jwt.UUCP> <2496@bucsb.UUCP> <274@tree.UUCP> <552@rna.UUCP> <13546@watdragon.waterloo.edu> <3718@nunki.usc.edu> <8197@phoenix.Princeton.EDU> <1972@dataio.Data-IO.COM>
Reply-To: pozar@hoptoad.UUCP (Tim Pozar)
Organization: Late Night Software (San Francisco)
Lines: 28

In article <1972@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
>DOS's basic disk I/O is generally considered fast. In fact, I once saw a
>magazine article where the author went to a lot of trouble trying to duplicate
>the speed of DOS's COPY C:*.* command. He couldn't do it faster. (Though
>he might have been merely incompetent! :-))
>Also, I've never heard anyone complain about the disk I/O speed and blamed
>it on DOS. It's always been blamed on:
>	1. Slow hardware speeds.
>	2. Should use a (ram hungry) disk cache.
>	3. Should use non-blocking I/O.
>The proof of this is that practically no programs go around DOS to do
>disk I/O for speed reasons.

     I know of several authors and programmes that speficly do
an end run around MS-DOS's disk i/o.  Things like findfirst and
findnext are increadibly slow.  Part of the reason that these
people are bypassing the system is that they are writing
programmes that need to search for on file out of normally 500
to a 1000 files in a subdirectory.  On a standard PC (4.77MHz)
a find can take several minutes.

	   Tim
 
-- 
 ...sun!hoptoad!\                                     Tim Pozar
                 >fidogate!pozar               Fido:  1:125/406
  ...lll-winken!/                            PaBell:  (415) 788-3904
       USNail:  KKSF / 77 Maiden Lane /  San Francisco CA 94108