Rendering noise is very slow

[Shnatsel]

When decoding a GNOME desktop background, jxl-oxide takes more than 3x longer to decode the file compared to djxl v0.8.1

jxl-oxide spends 71% of the time in jxl_render::features::noise::render_noise on the main thread. You can see it for yourself on the profile: https://share.firefox.dev/3ZQgu1s

This issue is a blocker for GNOME's glycin, the backend for GNOME's default image viewer and soon the image library to be used for everything GNOME from switching from libjxl to jxl-oxide.

[Shnatsel]

You can find the files to reproduce my measurements here: https://gitlab.gnome.org/GNOME/gnome-backgrounds/-/tree/main/backgrounds

I've profiled the adwaita-d.jxl file.

[tirr-c]

No surprise that it's slow, it hasn't been looked in for quite a while... I suspect that it's init_noise that takes a long time, which is single-thread and not quite cache friendly. I'm on a way of rewriting this...

[Shnatsel]

I cannot find init_noise on the profile, the profiler just points to render_noise. Although it's possible that it got inlined.

Looking at the code, it does look like it would be very slow. It is single-threaded and performs floating-point operations for every pixel. The Rust compiler doesn't autovectorize floating-point operations, so you get neither SIMD nor parallelism.

I've recently hit a similarly slow codepath in image-webp and replaced it with an integer approximation. At first I was hesitant to deviate from the precise floating-point result, but then it turned out that libwebp also uses an integer approximation that's even less precise.

[Shnatsel]

Never mind, you were correct!

I've re-measured with more precise debug info, and indeed init_noise by itself is taking up 48% of the entire execution time, while render_noise self time is much lower: https://share.firefox.dev/4fuQPkL

[tirr-c]

Working in the PR #401. It should be much faster now.