home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11988 < prev    next >
Encoding:
Text File  |  1992-12-29  |  1.4 KB  |  32 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!incom!orfeo!qb!vhs
  3. From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
  4. Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
  5. Message-ID: <1992Dec29.212344.20899@qb.rhein-main.de>
  6. Sender: vhs@qb.rhein-main.de (Volker Herminghaus-Shirai)
  7. Reply-To: vhs@rhein-main.de
  8. References: <1477@pacsoft.com>
  9. Date: Tue, 29 Dec 92 21:23:44 GMT
  10. Lines: 20
  11.  
  12. In article <1477@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
  13. > In an article, conor@lion.inmos.co.uk (Conor O'Neill) writes:
  14. > >But, given that 'fseek' is incredibly slow on most Unix systems,
  15. > >one could almost assume that Unix doesn't support random-access files.
  16. > 
  17. > What do you mean by this?  My understanding is that nothing is physically
  18. > being done by the call -- it simply sets the byte offset in the file table.
  19. > Is the copying of sizeof(off_t) bytes from user space to kernel space
  20. > what makes it "incredibly slow", in your opinion?
  21.  
  22. Or did he mix it up with M$-DOS fseek on files opened in "text mode".
  23. This is indeed incredibly slow because the file is searched for CR/LFs
  24. since CR/LFs count as only one byte (a logical linefeed) in that case.
  25. Another brilliant Bill Gates idea, ack!
  26.  
  27. --
  28. Volker Herminghaus-Shirai (vhs@qb.rhein-main.de)
  29.  
  30. Looks good on the outside, but -
  31.     intel inside
  32.