Date:	Tue, 24 Nov 92 13:22:55 EST
From:	rezaei AT tristan DOT TN DOT CORNELL DOT EDU (Mohammad Ali Rezaei)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	slow floppy performance

I am running djgcc 1.07; I will upgrade to 1.09 within a few days,
but I don't think the problem I am about to describe is fixed with
version 1.09. (Correct me if I'm wrong).

I was rather amazed at the slow disk performance, very noticable on
floppies, of the fread command. No matter how large I made the buffer
(passed to fread), the performance wouldn't increase. I should note that
the performance degradation was perhaps an order of magnitude over, say
dos's copy command. (yes, that bad). So I finally bit the bullet and
looked at the source for fread which lead me to _filbuf and eventually
to the read system call; (this is 1.09 source, and that's why I don't think
the problem is removed with 1.09). I noticed that no matter what was 
passed to fread, the read call in _filbuf, would read things one byte
at a time. 

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.
So the probelm is easyily fixed, or kludged, by a simple construct:
everytime you call fopen
fp=fopen(...);
you can add the lines
fp->_base=somebuffer;
fp->_bifsiz=somebuffer_size;
where somebuffer is just some buffer you allocate. (4096 appears to be
a good number for the buffer size).
This worked great and I got tremendous increase in floppy performance.

Q1) do we want to change djcc to do this all the time?
Q2) Does it affect hard drive performance? (I can't tell because
	my hard drive is heavily hard-cached).

BTW, split and merge from the standard distribtion exhibit this 
slow performance.

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:

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?
Q4) read boils down to an int 21 call. My understanding of int 21 calls
	is that they are robust and reliable (across different versions
	of DOS and different devices.) by they are slow. So is there
	a way we can speed this up?


phew! Excuse spelling/grammer errors, etc.
Please let me know if any of the inferences I made were incorrect.


							-Mohammad

- Raw text -