Date:	Sun, 13 Nov 1994 01:47:51 -0800
From:	John Nemeth <jnemeth AT cue DOT bc DOT ca>
To:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Subject:	Re: Disk I/O rates with DJGPP
Cc:	Charles Sandmann <sandmann AT new-orleans DOT neosoft DOT com>,
	Martin AT snsystems DOT co DOT uk, djgpp AT sun DOT soe DOT clarkson DOT edu

On Nov 13,  9:46am, "Eli Zaretskii" wrote:
} Subject: Re: Disk I/O rates with DJGPP
} > } indeed should make I/O faster.  I do maintain, though, that 10 more
} > } seconds is not such a long time to wait, even if you just bought this
} > } great ACME SCSI-II drive...
} >
} >      I disagree.  Of course, I'm another person that tried to squeeze
} > maximum performance out of DJGPP.  For some applications, I/O
} > performance is extremely important.  One of the main reasons I was
} 
} Could you provide an example of that kind of application?  I mean,
...
} Note that for non-multimegabyte files, the DJGPP penalty in *seconds*
} (not in %) is only a second or so, relative to what you get under
} real-mode DOS.

     In my case, I was reading compressed data in the 100'sK which
decompressed to 1.5MB maximum, but I needed to process the data in as
close to real time as possible, so even a half second improvement in
disk reading speed would have made a big difference.  Not having to
deal with 64K segments and working with 32 bit registers probably
saved me more time then I lost, but I needed all the speed I could
get.

     Besides, the faster the applicaiton, the happier the user.  If a
change to a larger transfer buffer size, which can be invisible to the
programmer, will help I/O throughput then it should be done.

}-- End of excerpt from "Eli Zaretskii"

- Raw text -