home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11974 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  1.5 KB
  1. Path: sparky!uunet!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. Date: 28 Dec 1992 16:09:02 -0000
  6. Organization: Hitachi Computer Products, OSSD division
  7. Lines: 23
  8. Message-ID: <1hnqdeINN15a@duca.hi.com>
  9. References: <fW0DHHa@quack.sac.ca.us> <1992Dec24.112422.12434@titan.inmos.co.uk> <1477@pacsoft.com>
  10. NNTP-Posting-Host: duca.hi.com
  11. Summary: it depends
  12.  
  13. In article <1477@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
  14. >In an article, conor@lion.inmos.co.uk (Conor O'Neill) writes:
  15. >>But, given that 'fseek' is incredibly slow on most Unix systems,
  16. >>one could almost assume that Unix doesn't support random-access files.
  17. >
  18. >What do you mean by this?  My understanding is that nothing is physically
  19. >being done by the call -- it simply sets the byte offset in the file table.
  20. >Is the copying of sizeof(off_t) bytes from user space to kernel space
  21. >what makes it "incredibly slow", in your opinion?
  22.  
  23. While it's true that there is not necessarily any I/O initiated by the
  24. call, fseek() generally invokes the lseek() system call, so you do
  25. have that overhead.
  26.  
  27. In addition, fseek() is generally moronic about checking whether the
  28. new file pointer is within the current buffer.  That is to say, it
  29. doesn't check.  So if you, say, try to read a file backwards, one byte
  30. at a time, you'll do as many reads as there are bytes in the file.
  31.  
  32.   -- David Wright, Hitachi Computer Products (America), Inc.
  33.      wright@hicomb.hi.com
  34.  
  35.  
  36.