home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11997 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.3 KB
  1. Path: sparky!uunet!munnari.oz.au!spool.mu.edu!hri.com!noc.near.net!news.hi.com!duca.hi.com!not-for-mail
  2. From: wright@duca.hi.com (David Wright)
  3. Newsgroups: comp.arch
  4. Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
  5. Message-ID: <1hshvfINN3et@duca.hi.com>
  6. Date: 30 Dec 92 11:15:43 GMT
  7. References: <1477@pacsoft.com> <1hnqdeINN15a@duca.hi.com> <28162@dog.ee.lbl.gov>
  8. Organization: Hitachi Computer Products, OSSD division
  9. Lines: 36
  10. NNTP-Posting-Host: duca.hi.com
  11.  
  12. In article <28162@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
  13. >In article <1hnqdeINN15a@duca.hi.com> wright@duca.hi.com (David Wright) writes:
  14. >>In addition, fseek() is generally moronic about checking whether the
  15. >>new file pointer is within the current buffer.  That is to say, it
  16. >>doesn't check.  So if you, say, try to read a file backwards, one byte
  17. >>at a time, you'll do as many reads as there are bytes in the file.
  18. >
  19. >Speak for yourself. :-)
  20. >
  21. >I wrote most of the 4.4BSD stdio (bugs and all---so far we have found
  22. >and fixed three or four).  My fseek() can read a file backwards fairly
  23. >quickly.  You will do better if you read() directly---no general
  24. >subroutine can be perfectly optimal for all tasks---but there is no
  25. >longer an order of magnitude slowdown for short backwards seeks when
  26. >reading.
  27.  
  28. OK, you're a genius :-)  My point was not that fseek() is inherently
  29. slow, just that some implementations were not well thought out.  I
  30. know you know how this all works, but judging from the email I've
  31. been getting, some people are confused.  So, tutorial time: 
  32.  
  33.  fseek is a library routine, and these libraries have their own
  34.  buffers, WHICH ARE UNRELATED TO THE FILE SYSTEM CACHE.  The idea
  35.  behind fseek, fread, etc, is to avoid doing many system calls when a
  36.  program wants to do many small reads.  Instead, the library routine
  37.  does one large read, then hands small chunks of data to its caller.
  38.  This way, the (relatively expensive) system calls are replaced by
  39.  (relatively cheap) procedure calls.  (I'm primarily considering
  40.  reading here.  Writing is a bit more complex.)
  41.  
  42.  Inefficiencies arise because a simple-minded version of fseek (and
  43.  most of them are) will not check to see whether the new pointer is
  44.  still within the current buffer -- it just assumes not and always
  45.  rereads the file.  
  46.  
  47. I hope this makes things clearer.
  48.