Date:	Wed, 25 Nov 92 08:59:56 EST
From:	DJ Delorie <dj AT ctron DOT ctron DOT com>
To:	rezaei AT tristan DOT tn DOT cornell DOT edu
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	slow floppy performance

>I found out that the FILE structure has a member that is for the
>purpose of buffering, namley, if we have
>FILE *fp;
>then fp->_base is the buffer address and fp->_bufsiz is the size of
>the buffer. fp->_base is set to NULL by fopen and _bufsiz to 0, that
>is what eventually causes the single charater read in _filbuf.

filbuf() automatically allocates the buffer when needed, if the FILE*
points to an actual file.

>fp->_base=somebuffer;
>fp->_bifsiz=somebuffer_size;

Bad idea.  Fix the library instead.

>Q1) do we want to change djcc to do this all the time?

Not *that* change.  fopen/filbuf is supposed to allocate a buffer of
size BUFSIZ automatically.  If that code has a problem, then fix *it*.

>So I measured the floppy perfomance again (using K&R's version of cp,
>if you care, copying from floppy to a ram drive) and found out that
>my cp was still half the speed of dos's copy. since cp uses read and
>write (not fread and fwrite) I went directly to the source for 
>read (read.s) and found out two interesting things:

Any I/O done with go32 will be slower than DOS because the data has to
be copied around more to get it into protected mode.

>Q3) the magic number 4096 appears in there. why? I know 4096 is several
>	sectors and is therefore a good number to use for a buffer size,
>	but why is it hard coded in read.s?

4096 is the size of the transfer buffer in go32.  Go32 cannot perform
any transfers larger than this in one shot, so read.s breaks it up for
it and copies it into the mapped transfer buffer to reduce overhead.

DJ
dj AT ctron DOT com
Life is a banana.

- Raw text -