One of the big differences between 2.2 and 2.3 is that we moved from pthread to std::thread, and made a number of corrections for thread safety.
e.g.
https://github.com/openexr/openexr/commit/eea1e607177e339e05daa1a2ec969a9dd12f2497
https://github.com/openexr/openexr/commit/bf0cb8cdce32fce36017107c9982e1e5db2fb3fa
The old pthread/windows native implementation can be re-enabled by setting the preprocessor define
ILMBASE_FORCE_CXX03. I am wondering if you might be able to benchmark against that version of the code as an experiment to get more information?
Sent: Monday, April 1, 2019 8:27:29 AM
To: address@hidden
Subject: [Openexr-devel] OpenExr 2.3 - slower write speeds for Uncompressed and Zip1
Hi,
At Foundry we’ve started testing the read performance of OpenExr 2.3 with Boost 1.66 as we move Nuke towards conforming to VFX Reference Platform 2019. Although the release notes don’t mention any changes
to file writing, we have charted (see graphic below) OpenExr 2.3 write performance against OpenExr 2.2 as we noticed a slowdown in our playback cache generation which uses OpenExr.
From Nuke, a checkerboard/colourwheel combination is generated and animated over 100 frames in order to eliminate file reading from the measurements. These 100 frames are written to disk using each compression
type, and the timings are averaged over 10 test runs. Certain compression types show an improvement which is great, however we’re concerned that Uncompressed and Zip1 are 13% and 9% slower respectively:
Have you benchmarked this on your side too, and have you noticed similar metrics?
Regards,
Tony
Tony Micilotta
Senior Technical Product Manager - Nuke Family
Tel:
+44 (0)20 7479 4350
Web:
www.foundry.com
The Foundry Visionmongers Ltd. - Registered in England and Wales No: 4642027 - Address: 5 Golden Square, London, W1F 9HT - VAT No: 672742224