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.

[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.