> I have found that MTPerLineTransformValidation - one of our slowest stress > test 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, o...
Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8312191 - Merge remote-tracking branch 'upstream/master' into JDK-8312191 - 8312191: ColorConvertOp.filter for the default destination is too slow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14910/files - new: https://git.openjdk.org/jdk/pull/14910/files/eeb6b4a6..2cb96be8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14910&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14910&range=00-01 Stats: 190879 lines in 4799 files changed: 92024 ins; 47575 del; 51280 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
