Moving C++ File Pointer, internal mechanism?

[armstrhu]

Hello,
I have a simple question on how a pointer to a location within a file (or even memory) is moved. Lets say I have a file which is 1,000,000 bytes long and my pointer is currently at byte 1. If I want to jump to byte 1,000,000 [seekg()], does the computer have to scan through all 999,999 bytes before reaching the 1,000,000 byte, or can it jump directly there? Basically, is it just as efficient to go from 1->1,000,000 as it is to go from 1->2? Thanks!

[JLBorges]

> If I want to jump to byte 1,000,000 [seekg()], does the computer
> have to scan through all 999,999 bytes before reaching the 1,000,000 byte

No.
(In a stream opened in text mode, we can't seek to an arbitrary position like 1,000,000 precisely because of this).


> is it just as efficient to go from 1->1,000,000 as it is to go from 1->2? Thanks

If we had been at 1,000,000 sometime in the recent past, the operating system may have cached the pages in memory; and seeking to and reading from there would not be inefficient (though it would be slower than going from 1->2).

Buffering and moving of characters to or from the actual file is handled by an associated stream buffer object.
To get an idea of what how a stream buffer works, see: http://www.mr-edd.co.uk/blog/beginners_guide_streambuf

[dhayden]

It depends on the underlying stream that you're seeking in. If it's an fstream() for a file on disk then seeking to position 1,000,000 is (almost) as fast as seeking to position 2. The difference is as JLBorges points out: the OS may need to read the data from disk. This isn't a small thing: going out to the disk can be nearly a MILLION times slower than just adjusting a pointer.

On the other hand, if the stream is a sequential access device like a tape drive, then yes, you have to move past 999,999 bytes first.

[armstrhu]

hey guys thanks for the replies, I took a quick scan through that link and it looks like really useful stuff. So my understanding is, because of the random access nature of a typical disk drive, it should in theory be exactly the same. However, because the HDD has to physically move the mechanical arm to reach that point, that motion becomes the practical limitation. Thanks again!

[dhayden]

An easy way to see the delay is to consider the rotational latency. Once the read head is over the track, you have to wait for the data on the disk to rotate under the head. The average wait time is 1/2 a rotation. So let's work some numbers.

If the disk spins at 10,000 RPM, that's 60 seconds/minute / 10,000 RPM = 6ms per rotation. So half a rotation is 3ms. I the processor runs at 3Ghz, that means the wait time is a million clock cycles.