🚀 go-pugleaf

In article <1477@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
>In an article, conor@lion.inmos.co.uk (Conor O'Neill) writes:
>>But, given that 'fseek' is incredibly slow on most Unix systems,
>>one could almost assume that Unix doesn't support random-access files.
>
>What do you mean by this?  My understanding is that nothing is physically
>being done by the call -- it simply sets the byte offset in the file table.
>Is the copying of sizeof(off_t) bytes from user space to kernel space
>what makes it "incredibly slow", in your opinion?

While it's true that there is not necessarily any I/O initiated by the
call, fseek() generally invokes the lseek() system call, so you do
have that overhead.

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.

  -- David Wright, Hitachi Computer Products (America), Inc.
     wright@hicomb.hi.com