AWARE [SYSTEMS]
AWare Systems, Home TIFF and LibTiff Mail List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2015

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2015.01.01 20:24 "Re: [Tiff] Fast TIFF Reading on Windows", by Aaron Boxer
2015.01.01 17:12 "Re: [Tiff] Fast TIFF Reading on Windows", by Bob Friesenhahn
2015.01.01 17:27 "Re: [Tiff] Fast TIFF Reading on Windows", by
2015.01.01 20:20 "Re: [Tiff] Fast TIFF Reading on Windows", by Aaron Boxer
2015.01.03 05:24 "Re: [Tiff] Fast TIFF Reading on Windows", by Edward Lam
2015.01.05 13:47 "[Tiff] Fwd: Fast TIFF Reading on Windows", by Aaron Boxer
[...]

2015.01.01 20:20 "Re: [Tiff] Fast TIFF Reading on Windows", by Aaron Boxer

On Thu, Jan 1, 2015 at 12:12 PM, Bob Friesenhahn <

bfriesen@simple.dallas.tx.us> wrote:

On Thu, 1 Jan 2015, Aaron Boxer wrote:

Can anyone recommend the very fastest way of reading TIFF files on

windows?

>> For example, there are several ways of reading in the file, including >> memory mapping. Has anyone benchmarked performance on

>> recent versions of windows?

You should be more specific. A common benchmark method is to read the same file repeatedly. I suspect that you are more interested in first-read performance of a large series of images which in total are far larger than system memory. These situations are completely different.

NTFS blocksize can be a factor and the blocksize is specified when the filesystem is created. The blocksize is important since blocksize amount of data will be read (perhaps wastefully) if any byte in the block is accessed. Likewise, larger blocks may result in less apparent fragmentation with large files. The NTFS blocks are still stored accross 512 byte or 4k byte disk sectors.

Windows does not seem to cache filesystem data as agressively as some other systems, which can be both a hinderance and a benefit.

Memory mapped file reads under Windows seem rather similar to Linux.

Thanks. Yes, my use case is: first-read of many 10-15 MB RGB uncompressed files. Unfortunately, I don't have control over how the files are stored, i.e. block size. One nice feature on Linux is fadvise, where I can specify FADV_SEQUENTIAL | FADV_DONTNEED, which would be right for my use case.