Seek() and Read() performance and tuning

[temisu]

Hi,

There are certain things I've "known" for certain for example that Seek() on FFS is slow if you need to seek to the end of the large file. However, I don't really know if my assumptions are correct and before I start to do some testing on my own maybe someone knows answers to these questions for certain and can help me.

In short, if I have an application that use dos.library Seek() and Read() a lot, what are the constraints I have to keep in mind. (working 2.0+ OS)

Specifically I'm wondering about following cases.

1. Seeking at large offsets. If the current file offset for reading in rather large. and I want to skip forward. Does it make a difference if I use OFFSET_BEGINNING or OFFSET_CURRENT for the Seek()? I sincerely hope that OFFSET_BEGINNING does not start counting blocks from the start of the file. Is the situation different if I want to Seek() backwards
2. Reading data by chunks. Dos Library reads are non-cached. My assumption is that it is best to read the data by block size chunks. Should they also aligned to block offsets?
3. Seeks versus reads. If Seek() is bad and I want to Seek() forward a bit. Does it make better to actually Read() the data instead?

Anyway, this might be me overthinking. If you have some insight please share.

Thanks.

[Thomas Richter]

Originally Posted by temisu

There are certain things I've "known" for certain for example that Seek() on FFS is slow if you need to seek to the end of the large file.

That depends on the number of buffers and on the size of the file. What the FFS has to do is to find the file link blocks and follow their links to the end of the file.

Originally Posted by temisu

In short, if I have an application that use dos.library Seek() and Read() a lot, what are the constraints I have to keep in mind. (working 2.0+ OS)

Also depends on how much you read and how you seek. Seek() and Read() directly go down to the file system. If these are a lot of tiny reads and seeks, it is better to add another layer of buffering between them such that some of the operations go to the buffer instead to the file system.


In principle, FRead() of the dos.library could do that, but it is not a very smart implementation, thus is a lot slower (this will change with 3.2), and there is no obvious Seek() counterpart.

Originally Posted by temisu

Seeking at large offsets. If the current file offset for reading in rather large. and I want to skip forward. Does it make a difference if I use OFFSET_BEGINNING or OFFSET_CURRENT for the Seek()?

No, that is all the same.

Originally Posted by temisu

Reading data by chunks. Dos Library reads are non-cached. My assumption is that it is best to read the data by block size chunks. Should they also aligned to block offsets?

It would certainly help as then the FFS can read data directly to your buffers instead of going though another buffer, and copying data over to you. That is, the read positions could be aligned to the block positions.

Originally Posted by temisu

Seeks versus reads. If Seek() is bad and I want to Seek() forward a bit. Does it make better to actually Read() the data instead?

No, that is all the same. Quite the reverse, a read by an entire block will pull this block from the device, a seek will just skip it.

[temisu]

Thanks, that makes sense