2016.01.25 23:27 "Re: [Tiff] OpenMP enabled libtiff", by Mikhail

I'm extremely interested in seeing libtiff faster as IO is the bottleneck of my application, and certainly native Windows IO commands with buffering disabled perform faster than libtiff. It I think there might be some motivation to run libtiff through `KCachegrind`, and see what percentage is spent where.

Perhaps,
  OpenMP might not be a bad idea if there is some particularity nasty
section...

On 1/25/2016 14:45, Bob Friesenhahn wrote:

>> I believe SSDs perform well under multiple reads, but this would have >> to be carefully bench-marked, of course.

For NVMe, this is very true, for SAS more true, for SATA (most common) not very true at all. But SSDs normally have low latency and a high transfer rate so multiple reads do not help so much. Multiple reads helps more for traditional hard disks, and particularly RAID arrays, where many reads can be scheduled for the hardware at once and the latencies are relatively large.

Thanks.

strips are processed by which threads. I will take a look at the code and see if I can come up with a simple way of doing this.

Are you talking about the simplified RGBA interfaces intended for "new" users? Serious applications do not use those interfaces.

It would be ideal to support reading/writing multiple strips/tiles at once using multiple threads on a single TIFF handle, with each thread allocating and holding its own allocated handle to store thread-specific data. This would require enhancements to the libtiff API.