[fl]seek mechanism

[Conor P. Cahill]

In article <1631 at unccvax.UUCP>, cs00chs at unccvax.UUCP (charles spell) writes:
> Does the kernal optimize seeks within an open file?

There is not much to optimize because the seek operation is one of the
simplest (both in overhead & implementation) system calls in the kernel.
It simply sets the file offset to the new value.  The difference between
adding one byte to the current value and storing the new value would
be unmeasurable (especially when compared to the overhead of the 
context switch into kernel mode to perform the system call).

I have worked on systems that had special system calls to perform
an lseek and read/write in a single system call.  The addition
of these system calls had a significant (positive) impact on the
performance of database software which routinely perform an lseek
with just about every read/write.

> if you have a file descriptor that is currently at offset 500,000 of a
> 1,000,000 byte file, which would be faster (to get to byte 500,001)?:
> 
> lseek(fd, 1L, 1);             -OR-               lseek(fd, 500001L, 0);

See above.

> 
> with file descriptors:
> fseek(fp, 1L, 1);             -OR-               fseek(fp, 500001L, 0);

For the file POINTERS (not descriptors) I'm not too sure if there is 
any local (stdio) operations associated with discarding the current buffer
and getting a new one.  My *guess* would be that there is no measurable
difference, but that is only a non-educated guess.


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+