If I have a C code
off_t off = ftello(f);
fseeko(f, some_location);
// do some work
fseeko(off);
Is the second fseeko as slow as the first one? I had thought the file blocks are always cached, so the second one could be much faster.
In my profiling results on Linux, the second fseek takes similar cost. Is this expected?
In most implementations, the fseek call is almost free since all it does is set the position in the FILE object. The cost will be incurred when you actually read data. At that point, it is very likely that rereading an already read block will benefit from the buffer cache. But it is also quite possible that the OS is doing speculative read-ahead so that blocks following recently read blocks are also in the buffer cache (as could be the case with your second seek).
For writing, measuring times is even more complicated because the blocks written are not necessarily committed immediately to permanent storage; the write system call returns as soon as the data has been copied into the buffer cache.
Is the second fseeko as slow as the first one?
It can be.
You see what you say about caching holds, but only cases where you deal with multiples of the FS block size.
I would suggest to read more in How is fseek() implemented in the filesystem?, since "The fseeko() function is identical to fseek(3)(see fseek(3)), respectively, except that the offset argument of fseeko().", as the ref suggests.
