Date: Wed, 25 Nov 92 08:59:56 EST From: DJ Delorie 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.