xseek(y,z,0) .vs. xseek(y,z,1)

[der Mouse]

In article <6463 at shamash.UUCP>, jwabik at shamash.UUCP (Jeff Wabik) writes:

> Does anyone know the algorithms for lseek and fseek? 

> I.E.  Specifically, which is faster and why:

> 	for (i=10000; i < 100000000; i+=10000) {
> 	   fseek(fp,i,0);
> 	      ...	}

> 	for (i=10000; i < 100000000; i+=10000) {
> 	   fseek(fp,10000,1);
> 	      ...	}

Lseek speed should be approximately the same for relative-to-beginning
and relative-to-current seeks; relative-to-end seeks can be slow
because they usually get transformed into relative-to-beginning seeks
by finding out the file size and tacking on the specified offset.

Fseek is another can of worms and will depend on your stdio library.
If the library is smart, the efficiency difference should be small to
zero, as with lseek.  If the library is dumb, either or both could be
horrible.

But a better point would be, which is correct?  Presumably if you are
seeking around, you will also do I/O (why else bother seeking, right?).
But if you do I/O, then the code with the relative seek no longer goes
to the same places as the code with the absolute seek!  (Besides, the
offset argument to fseek is a long - shouldn't that second one say
10000L?  Since you omitted the declaration for i, I'll let you off the
hook on the first one. (:-)  You don't specify what system, so I'm
using my system (mtXinu 4.3+NFS) as a reference, but it seems likely to
me that fseek offsets have always been longs, ever since the '11.)

					der Mouse

			uucp: mouse at mcgill-vision.uucp
			arpa: mouse at larry.mcrcim.mcgill.edu