From: Charles Sandmann <sandmann AT new-orleans DOT NeoSoft DOT com>
Subject: Re: Disk I/O rates with DJGPP
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 6 Nov 1994 16:34:51 -0600 (CST)
Cc: Martin AT snsystems DOT co DOT uk, djgpp AT sun DOT soe DOT clarkson DOT edu

> What I would like to point out is that performance penalty for using
> DJGPP is really not so bad.  (27 seconds vs 16 seconds)

Well, I disagree.  It's like taking that nice new high speed SCSI drive
and turning it into an MFM drive when running under DJGPP.  That's why
I plan to make sure the best performance we know how will be available
in V2 with nothing more than a stubedit.  (BTW, it is more than just
the transfer buffer size, but that is a big factor).

> possible speed of I/O operations, but they should know from the
> onset that the speed of real-mode I/O cannot be reached from
> DOS-extended programs (due to the necessity of moving the data from/to
> low memory), even if all other inefficiencies are sorted out.

Copying the memory is a small overhead (almost neglible).  The mode
swaps from protected to real to protected are the bottleneck.  The big
transfer buffer also reduces the number of these needed.

> What would *really* be e big win is writing something like 32bit disk
> access in Windows.  Quite a project, I would say.  I don't see how
> somebody other tham MS would succeed here, because this requires
> such intimate relationship with the DOS (undocumented) internals.

While I have such code, maintaining this is a nightmare.  If you need
the high performance this badly, you need a new Operating System.  I
would suggest OS/2 or Linux.  Native GCC is available for both.