jwabik@shamash.UUCP (Jeff Wabik) (06/06/88)
Does anyone know the algorithms for lseek and fseek?
I.E. Specifically, which is faster and why:
Sample #1:
for (i=10000; i < 100000000; i+=10000) {
fseek(fp,i,0);
.
.
}
Sample #2:
for (i=10000; i < 100000000; i+=10000) {
fseek(fp,10000,1);
.
.
}
Thanks in advance ..
-Jeff
---
Jeff A. Wabik INTERNET: jwabik@shamash.cdc.com
____ ____ UUCP: {rosevax,umn-cs,bungia,ems}!shamash!jwabik
/ ___||___ \
| |___ ___| | Control Data Corporation - Better living through 64 bits.
\____||____/
Live long and program.henry@utzoo.uucp (Henry Spencer) (06/07/88)
In most implementations it isn't going to make any difference, because the
1 case is converted into the 0 case before anything else is done. It's
strictly a convenience issue, unless your files are so huge that a long
isn't big enough to describe them.
--
"For perfect safety... sit on a fence| Henry Spencer @ U of Toronto Zoology
and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henrychris@mimsy.UUCP (Chris Torek) (06/09/88)
In article <1988Jun7.162241.14545@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In most implementations it isn't going to make any difference, because the >1 case is converted into the 0 case before anything else is done. Actually, in at least one implementation (4.[23]BSD), fseek(..., 0) is often slower than fseek(..., 1), because 0 (L_SET) calls lseek() once to find out where the offset is now, in case data in a pre-read buffer is already correct, then again if the data is not useful (belongs to the wrong region of the file). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mouse@mcgill-vision.UUCP (der Mouse) (06/13/88)
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