LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
Previous by Thread
Next by Thread
Previous by Date
Next by Date
The TIFF Mailing List Homepage
Archive maintained by AWare Systems
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.
OpenMP might not be a bad idea if there is some particularity nasty
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
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.