Mail Archives: djgpp/1996/03/19/06:26:11
> 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.
- Raw text -