We have improved the cmm code over a few releases and mostly resolve the
JDK-8041125. But I have executed an attached test case under a profiler and
found that:
* less than 10% is an actual pixel transformation inside littlecms
* 30% is a native up-calls like getXXField
* 30% is incoming arrays coping
* 30% results array saving
* others
This change removes the native up-calls and passes all data from the java side.
Notes:
* The above numbers are true for the "pure Java" implementation in the test
case, where we transform the image pixel by pixel, if the image is big and we
transform it at once via filter then we spend most of the time in the littlecms
code
* JDK7 uses 4 threads in the filter implementation, but single-threaded jdk17
is faster because of some code improvement in cmm profiles initialization
during the "cold start". And probably because the image is not so big(625x843).
* If the size of the image will be increased and the warmup is done the jdk7
will be 4x time faster, this is another opportunity that I'll try to resolve
later.
Tested on macOS (fastest result after a few runs):
||JDK 7 | JDK 8 | JDK 17 | FIX |
|----|----|----|----|----|
|With filter | 307 ms | 456 ms | 242 ms | 236 ms |
|In pure Java| 1672 ms | 389 ms | 300 ms | 259 ms |
JMH before/after the fix
`ColorSpace.toRGB/fromRGB/toCIEXYZ/fromCIEXYZ(new float[]{1,1,1})`
single threaded and multi-threaded(MAX = 30):
https://jmh.morethan.io/?gists=b1edd5e5ebeb1b76867b2112be30145d,fc86ce4a6f8f2f49e9ab512ef641c11b
-------------
Commit messages:
- Update LCMS.java
- initial fix
Changes: https://git.openjdk.java.net/jdk/pull/5835/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5835&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8041125
Stats: 137 lines in 4 files changed: 9 ins; 101 del; 27 mod
Patch: https://git.openjdk.java.net/jdk/pull/5835.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/5835/head:pull/5835
PR: https://git.openjdk.java.net/jdk/pull/5835
