search

etemesi254 / zune-image

A fast and memory efficient image library in Rust
Other
327 stars 30 forks source link

JPEG-XL: decoding is extremely slow #179

Open hillin opened 7 months ago

hillin commented 7 months ago

I understand that zune-image uses jxl-oxide for JPEG-XL decoding and it's probably them are to blame, but since zune-image aims to be fast on all formats (hopefully, and eventually), I'm firing this issue here.

Again, here are some benchmarks:

zune encode jpeg        time:   [3.6447 ms 3.7083 ms 3.7759 ms]
zune encode jpeg-xl     time:   [4.4756 ms 4.5254 ms 4.5794 ms]
zune decode jpeg        time:   [936.37 µs 947.12 µs 958.96 µs]
zune decode jpeg-xl     time:   [54.592 ms 55.438 ms 56.382 ms]
etemesi254 commented 7 months ago

Yea, I sadly didn't write the decoder, that is a format that scares me. :)

I wish i had infinite time to optimize them, but working on it

hillin commented 7 months ago

No worries, this is just for the backlog. Keep up the great work!

Shnatsel commented 7 months ago

I've been doing some profiling on jxl-oxide and the author has been continuously working on improving performance, including based on my findings.

A 50x slowdown compared to JPEG is unexpected. I suggest you submit the file that causes such a large runtime to jxl-oxide issue tracker; it is possible that it is hitting an abnormally slow codepath that would be easy to optimize.

etemesi254 commented 7 months ago

I also realized I was using a very ancient version, updated in https://github.com/etemesi254/zune-image/commit/23c8bb1dd0c095b0776c70c4b659f737b4615463 so it might have lacked the optimizations above, so they should probably be rerun

Shnatsel commented 3 months ago

It seems parallel decoding for jxl-oxide was not enabled. Enabling it should help performance: https://github.com/etemesi254/zune-image/commit/72f16e44556b1f06367ca09273a6f06306f60870