Costs of Seek()'s

[Jose]

Does anyone have any idea of the lost time/performance by doing Seeks() ? The manufacturer's present the average seek(search ?...) time in ms but that's a bit irrelevant as it would depend on the distance being seeked, wich will be very big for files distant from one another, but smaller if in the same file. It's in the last context that I'm interested, although the seek time will raise with filesize I guess.

Basically I want to know if it's feasible to save some data at the end of the file when saving, wich will help later when loading. It's easier to add some stuff at the end to avoid reading the data twice in memory to get it's size for example, wich will get slower for big files (yes only for very BIG ones I know...). This means for loading one will 1st need a seek to the end of the file to read that part, followed by a seek to the beggining to continue (no more seeks after that). So  I'd like to know the cost of this in the best/worse case scenerious.

[Karlos]

Well, it depends. On a lot of factors too, everything from the hardware medium to the filesystem.

In practise, howver, I've found fseek() operations fast for hard drive files of any size when in read mode. I expect its more than likely it simply interrogates the underlying filesystem at the implementation level to find out the size rather than physically looking for the end of the file ;-)

(that's your hint to do the same, btw)

[Piru]

fseek and Seek() are completely different beasts.

dos.library Seek() works on unbuffered files, whereas stdio fseek() works on buffered I/O. However, in this case if you seek to end of file, it's pretty much one and the same.

Also, the speed of file seeking has no relation to hard disk seek speed reported by the hardware manufacturer. The file seeking speed is mostly decided by the filesystem implementation. For example FFS is dead slow when seeking large files, regardless if you have 15krpm uw scsi HDD. Similarily, good filesystem can seek to end of file without actually doing any I/O operations, making the seek instant, regardless of the actual speed of the underlying medium.

[Jose]

Great, I'll try that out.
BTW, that's got to be one of the coolest avatars I've seen :-)

[Jose]

(Karlos)
"...I expect its more than likely it simply interrogates the underlying filesystem at the implementation level to find out the size rather than physically looking for the end of the file"

(Piru)
"...Similarily, good filesystem can seek to end of file without actually doing any I/O operations, making the seek instant, regardless of the actual speed of the underlying medium."

Doesn't that depend also on the speed the actual HD seeks ? I'm assuming there must be some physicall changes to start reading at a different place, I don't want just the seek to be fast but the seek and the actual time data starts being read.

[Karlos]

Piru wrote:
fseek and Seek() are completely different beasts.

dos.library Seek() works on unbuffered files, whereas stdio fseek() works on buffered I/O. However, in this case if you seek to end of file, it's pretty much one and the same.

I know. I was trying to hint that fseek()ing to the very end of the file probably doesn't involve any real IO using Seek(), and that perhaps examining the appropriate FileInfoBlock.fib_Size might be a quick way of working out how big a file is before opening it ;-)

[Piru]

Doesn't that depend also on the speed the actual HD seeks ? I'm assuming there must be some physicall changes to start reading at a different place, I don't want just the seek to be fast but the seek and the actual time data starts being read.

With bad filesystems yes, with good filesystem no. As I said before, good filesystems can seek to end of file without doing any device I/O.

Don't confuse filesystem and device I/O here.