I have found that MTPerLineTransformValidation - one of our slowest stress tests spends most of the time not in the code related to the colors conversion(as it was intended) but in the initialization of the native cmm-transforms.
ColorConvertOp sharedOp = new ColorConvertOp(srcCS, dstCS, null); <-- slow BufferedImage dst = sharedOp.filter(src, null); The code above triggers the next sequence: 1. The destination buffered image is not set so it should be created [automatically](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L551) ->> 2. The buffered image requires the new color [model](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L588) ->> 3. The color model requires new color [space](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L563) ->> 4. The color model initialize some [LUTs](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorModel.java#L1816), **and cache it per color space** ->> 5. When the ColorConvertOp is used for the first time the color space caches some state internally if the format of the src/dst image is not changed So the critical thing above is to minimize the creation of the new color spaces, since for each new space all optimizations above should be repeated. Unfortunately, when we create the ColorConvertOp using standard icc_profile/icc_colorspace we store the profile only and [lost](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L150) the reference to the initial color space. And when later we decide to create a color model we create the new icc_color space->all optimizations resets. We do not save the reference to the color space because that way we distinguish the icc_colorspace saved using profiles, and non-icc_color spaces used as is. I think all that code should be reworked to take into account the current issue. But for now, we can fix it at least for standard types. **Important notes**: * Performance of MTPerLineTransformValidation test is increased(on my system from 3m30s to the 14s) - the number of used native transforms changed from 80000 to ~500. It can have a side effect since a few crashes(exit code 134) were reported for this test. The crashes of this test and others may disappear since the memory pressure is decreased, or the number of crashes can increase because the code for transforming will be executed in parallel more often. * The patch also affects the noop color conversion when the color space of the src and dst are the same, for example, if both are SRGB then: <img width="996" alt="cmm" src="https://github.com/openjdk/jdk/assets/14138494/caf42003-f37f-400b-8271-d7ef32eb963d";> ------------- Commit messages: - 8312191: ColorConvertOp.filter for the default destination is too slow Changes: https://git.openjdk.org/jdk/pull/14910/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14910&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312191 Stats: 82 lines in 2 files changed: 80 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14910.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14910/head:pull/14910 PR: https://git.openjdk.org/jdk/pull/14910
