Welcome, Guest. Please login or register.

Author Topic: Costs of Seek()'s  (Read 2625 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show all replies
    • http://www.iki.fi/sintonen/
Re: Costs of Seek()'s
« on: January 27, 2007, 05:14:29 PM »
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.
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show all replies
    • http://www.iki.fi/sintonen/
Re: Costs of Seek()'s
« Reply #1 on: January 27, 2007, 06:14:47 PM »
Quote
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.