2016.01.25 18:25 "[Tiff] OpenMP enabled libtiff", by Aaron Boxer

2016.01.26 19:32 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer

On Tue, Jan 26, 2016 at 12:10 PM, Bob Friesenhahn <

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

> On Tue, 26 Jan 2016, Aaron Boxer wrote:
>
>>

Yes, so you don't think there is a "quick and dirty" solution for speeding up compressed reading?

For my purposes, I am only interested in reading uncompressed files, so TIFFClientOpen

on a memory buffer should be good enough.

Libtiff is very fast at reading from uncompressed files and I don't see much performance penalty as compared with accessing files using system APIs.

Yes, I can see that. Although, the fact that people use multiple TIFF handles for a single file seems to indicate that there are performance gains to be had

by threading.

>
> But, I still think it is a shame to leave the library single threaded in

this multi-core world.

It is just finding the time to work on improvements.

It is likely that adding threading would just make it slower for many common cases and it adds a link-time dependency which otherwise does not exist. It is much better to enable threaded applications to make better use of libtiff when accessing one file. What works in one use case may be totally inappropriate for another. Preserve the application writer's freedom to chose the best solution for the application. Most importantly, we can not afford to break the existing libtiff API and ABI.

> Agreed - don't want to change API/ABI