🚀 go-pugleaf

In article <28162@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
>In article <1hnqdeINN15a@duca.hi.com> wright@duca.hi.com (David Wright) writes:
>>In addition, fseek() is generally moronic about checking whether the
>>new file pointer is within the current buffer.  That is to say, it
>>doesn't check.  So if you, say, try to read a file backwards, one byte
>>at a time, you'll do as many reads as there are bytes in the file.
>
>Speak for yourself. :-)
>
>I wrote most of the 4.4BSD stdio (bugs and all---so far we have found
>and fixed three or four).  My fseek() can read a file backwards fairly
>quickly.  You will do better if you read() directly---no general
>subroutine can be perfectly optimal for all tasks---but there is no
>longer an order of magnitude slowdown for short backwards seeks when
>reading.

OK, you're a genius :-)  My point was not that fseek() is inherently
slow, just that some implementations were not well thought out.  I
know you know how this all works, but judging from the email I've
been getting, some people are confused.  So, tutorial time: 

 fseek is a library routine, and these libraries have their own
 buffers, WHICH ARE UNRELATED TO THE FILE SYSTEM CACHE.  The idea
 behind fseek, fread, etc, is to avoid doing many system calls when a
 program wants to do many small reads.  Instead, the library routine
 does one large read, then hands small chunks of data to its caller.
 This way, the (relatively expensive) system calls are replaced by
 (relatively cheap) procedure calls.  (I'm primarily considering
 reading here.  Writing is a bit more complex.)

 Inefficiencies arise because a simple-minded version of fseek (and
 most of them are) will not check to see whether the new pointer is
 still within the current buffer -- it just assumes not and always
 rereads the file.  

I hope this makes things clearer.