[fl]seek mechanism

[Chris Torek]

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

This question is basically meaningless, because the kernel (note spelling)
code for lseek---minus error checks, and with names expanded---is:

	fp = this_process.open_files[file_descriptor];
	switch (whence) {
	case 0: fp->f_offset = offset; break;
	case 1: fp->f_offset += offset; break;
	case 2: fp->f_offset = fp->f_inode->i_file_size - offset; break;
	}
	return;

Offsets from the end of the file are a tiny bit slower than other offsets
due to the extra indirection required to get the file size.  If a system
call requires 100 machine instructions (this estimate is probably a bit
low), case 2 might be 1% slower.

>[to go from byte 500000 to byte 500001] with file descriptors:
>fseek(fp, 1L, 1);             -OR-               fseek(fp, 500001L, 0);

Presumably you mean `with stdio'.  In general, existing stdio
implementations are better with offsets from 0 than with offsets from
`current point' or `end of file', so the latter would be faster.  But
`(void) getc(fp)' would be faster still.  Stdio has to make two
lseek calls per fseek, in the most general case, since it needs to
first discover where it is (consider, e.g., `prog >> output', which
might be at byte 5131 when it begins).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris