RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v5]
Jeremy Wood
jwood at openjdk.org
Tue Jan 6 15:58:21 UTC 2026
On Tue, 6 Jan 2026 15:50:05 GMT, Jeremy Wood <jwood at openjdk.org> wrote:
>> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time.
>>
>> This PR uses System.arraycopy instead, and it shows approx a 10% improvement.
>>
>> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases:
>>
>> <img width="596" height="366" alt="Screenshot 2025-12-27 at 9 14 19 PM" src="https://github.com/user-attachments/assets/73583cb2-eda0-47a8-b818-735a1835f1e8" />
>>
>> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.)
>>
>> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>
> 8374377: move jmh test to java/awt/image
>
> This is in response to:
> https://github.com/openjdk/jdk/pull/29004#issuecomment-3713285051
@ jayathirthrao , OK, I moved the JMH test to java/awt/image .
(I'm still unfamiliar with how the JMH tests are used overall. For my part: I'm fine with discarding this JMH test altogether. I wanted it (or something like it) to verify that this PR improved performance. But now having proven that: keeping it around indefinitely may be overkill...?)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3715243555
More information about the client-libs-dev
mailing list