Date: Tue, 19 Mar 1996 14:13:12 +0300 (MSK)
From: "Alexander V. Lukyanov" <lav AT video DOT yars DOT free DOT net>
Message-Id: <199603191113.OAA05864@video.yars.free.net>
To: djgpp AT delorie DOT com, rbabcock AT cfa DOT harvard DOT edu
Subject: Re: Faster floppy I/O

> 2. The above change still left the indexing time roughly twice as long as
> 	with Turbo C or djgpp 1.2.  The cause is inefficiency in fseek.  Any fseek
> 	call seems to discard buffered information and generate a DOS seek call
> 	even if the seek could be accomplished by moving a pointer into the
> 	buffered file data.
>
>    Solution: a routine my_fseek which seeks by moving pointers if possible,
>    and otherwise calls the library fseek.  (Turbo C timing above already used
>    this trick.)  Result: time reduced to 3.3 seconds, 20 times faster than
>    the 69 second timing which started this exercise.  One question remains:
> 	why was v1.2 not as slow as v2 with a small xfer buffer?  It seems to use
> 	the same algorithm.
>
> My_fseek is only used for reading, so I didn't have to worry about some of
> the cases which the library fseek handles.  Would anything break if the
> library fseek handled short seeks, at least for reads, by moving a pointer if
> the seek destination were already in the buffer?

The only such a thing I know of is lseek()'ing after an ungetc(). Maybe it is
reasonably to add a flag which will indicate whether there was an ungetc()
in the current buffer data.