zip decompression and multithreading

Uwe <[email protected]> Mon, 4 Jun 2018 18:22:45 +0200
Newsgroups gmane.comp.video.openexr.devel
Organization Science-D-Visions
Message-ID <[email protected]>
Hello everyone,

I am using openexr-2.2.1 on Linux and OSX.

I'm developing an application which loads a sequence of zip-compressed 
EXR-files
and converts them into some kind of archive. I would like to load and 
dispatch
images multithreaded. I'm testing my application on a 12-core machine 
running linux,
so, watching performance by means of 'top' (the shell command) should
ideally give a performance of nearly 1200%, but I get only 150%. If I 
analyze this
with gdb, I see that in fact I have 12 threads (the ones I created myself
outside openexr), but 11 of them are waiting at some mutex within 
openexr, while the 12th
is busy decompressing somewhere inside zlib. What I would like to have 
is 12 threads
decompressing...

One solution seems to be to compile openexr with option 
--enable-threading=false,
so that openexr uses a single thread for everything, but my applications
runs 12 threads reading exr-files.
If I do this, I nearly get the full performance, something around 1050% 
for 12 cores,
but this might slow down other decompression modes.

My question is:
1. Is there some reason for openexr to use only one thread for 
decompressing
with zip? As far as I know zlib is thread-safe, so I'm puzzled...
2. Or is there a way to enforce multithreading during zip-decompression?

Best regards
Uwe Sassenberg