Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.sys.ibm.pc
Subject: Re: DOS is fast? (Was Re: Why unix doesn't catch on)
Message-ID: <1972@dataio.Data-IO.COM>
Date: 8 May 89 21:15:32 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>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 24

In article <8197@phoenix.Princeton.EDU> jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) writes:
<In article <3718@nunki.usc.edu< sawant@nunki.usc.edu (Abhay Sawant) writes:
<   What performance? OK, I guess your point is that it's as fast as it
<is because it was written in assembly. Perfectly valid... but ask all
<the programmers who have to deal with writing to the video RAM about how
<fast it is. :-) [Incidentally, ARE there any parts of DOS which are
<generally acknowledged as being fast?

The reason the video I/O is such a dog is because of the BIOS, not DOS.
The BIOS video I/O is so miserably slow that practically any programmer
can do it faster. Hint: a major reason is that a BIOS function is
necessary that writes a *string* at a time!

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.