Path: utzoo!attcan!uunet!husc6!bloom-beacon!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.lang.c Subject: Re: xseek(y,z,0) .vs. xseek(y,z,1) Keywords: How does it work? Is one faster? Message-ID: <1164@mcgill-vision.UUCP> Date: 13 Jun 88 10:04:40 GMT References: <6463@shamash.UUCP> Organization: McGill University, Montreal Lines: 38 In article <6463@shamash.UUCP>, jwabik@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@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu