rustc 1.87.0 and rustc beta performance regression

[arichnad]

Hello, I saw a performance regression using rustc 1.87.0 and rustc beta.

I'm using the master branch of image-png ( 56fbdc5 ).

for version in 1.86.0 1.87.0 beta nightly; do
  rustup install --profile minimal $version && rustup run $version cargo run --release --example=corpus-bench
done

I'm including a total encoding line of each version here from one computer, but I ran this on multiple hosts, and noticed similar results (similar ratios).

• 1.86.0 233 mps 0.722 GiB/s
• 1.87.0 133 mps 0.412 GiB/s
• beta 132 mps 0.410 GiB/s
• nightly 215 mps 0.665 GiB/s

The ratio is more visible if you disable png compression.

Let me know if there is any more information I can provide, thank you!

[197g]

The nature of our filter implementation makes performance quite dependent on auto-vectorization. If the issue is specific to a rustc version, there is very likely an llvm regression that I would encourage reporting upstream. What's the precise environment (target tuple, host tuple, cpu, image testsuite) if someone should try to replicate this issue?

[fintelia]

Rustc 1.87.0 upgraded to LLVM 20 so there's a good chance that's related to the slowdown.

If it is the unfiltering that's the problem, the unfilter benchmark should show that. Would be good to construct a minimal repro and report upstream, though if the performance is better on nightly that may mean its already been fixed and just needs to be rolled out to beta/stable.

[fintelia]

On Linux with an AMD Ryzen 5600X, I'm seeing a performance drop in the paeth4 unfiltering code. Not as severe as OP, but still significant:

unfilter/filter=Paeth/bpp=4
                        time:   [11.177 µs 11.192 µs 11.211 µs]
                        thrpt:  [1.3610 GiB/s 1.3633 GiB/s 1.3652 GiB/s]
                 change:
                        time:   [+17.275% +17.435% +17.596%] (p = 0.00 < 0.05)
                        thrpt:  [-14.963% -14.846% -14.730%]
                        Performance has regressed.

[Shnatsel]

There's also a big drop in adler32 performance in v1.87. It's fixed on v1.88 beta: rust-lang/rust#142603

[arichnad]

@197g @fintelia Oops sorry I missed your messages Friday!

target tuple, host tuple

$ rustup run nightly rustc -vV
rustc 1.89.0-nightly (45acf54ee 2025-06-16)
binary: rustc
commit-hash: 45acf54eea118ed27927282b5e0bfdcd80b7987c
commit-date: 2025-06-16
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5
$

cpu

I tested on Intel(R) Xeon(R) W-11865MRE and 12th Gen Intel(R) Core(TM) i9-12900H and noticed similar results (ratios) on both.

image testsuite

Like a docker? I will test this in any docker you'd like.

If it is the unfiltering that's the problem, the unfilter benchmark should show that

I imagine it's not unfiltering that is the problem since I see a much smaller difference in the unfilter benchmark?

for version in 1.86.0 1.87.0 beta nightly; do
	echo $version
	rustup install --profile minimal $version
	rustup run $version cargo bench --bench=unfilter --features=benchmarks unfilter/filter=Sub/bpp=2
done

(trimmed)

1.86.0
                        time:   [981.70 ns 986.09 ns 990.77 ns]
1.87.0
                        time:   [1.1637 µs 1.1664 µs 1.1690 µs]
beta
                        time:   [1.1529 µs 1.1610 µs 1.1684 µs]
nightly
                        time:   [1.1433 µs 1.1457 µs 1.1480 µs]

I'm not as surprised by this small change in unfilter: I'm more surprised by the larger change in corpus-bench.

[Shnatsel]

@arichnad by "image testsuite" we mean the images you're running corpus-bench on.

Do I understand correctly that you're using the qoi benchmark suite, as recommended by the README of corpus-bench? Nevermind, wrong corpus-bench

[arichnad]

@Shnatsel yeah the default: PathBuf::from(".") which drops into the tests/ directory of 56fbdc5 .

[Shnatsel]

Okay, I can reproduce this on Zen 4 by running cargo run --release --example=corpus-bench in this repository:

1.86: 0.736 GiB/s      251 mps  0.777 GiB/s
1.87: 0.383 GiB/s      236 mps  0.732 GiB/s
nightly: 0.734 GiB/s      244 mps  0.755 GiB/s

On 1.87 encoding performance drops like a rock, most likely because of the simd_adler32 regression: rust-lang/rust#142603

Nightly fixes it but performance doesn't come all the way back up, which I guess could be explained by Paeth filter in the RGB case not autovectorizing?

This benchmark is rather noisy, I am getting significantly different numbers from run to run.

[Shnatsel]

I ran a benchmark on the other corpus-bench and profiled it for good measure. There isn't really a huge difference between 1.86 and latest nightly.

rustc 1.86.0 (05f9846f8 2025-03-31)

image-rs PNG:     367.902 MP/s (average) 310.837 MP/s (geomean)

Profile: https://share.firefox.dev/45ndMFk

rustc 1.89.0-nightly (586ad391f 2025-06-15):

image-rs PNG:     366.895 MP/s (average) 308.382 MP/s (geomean)

Profile: https://share.firefox.dev/4e8eIzx

Conclusions

Looking at the profiles, unfiltering got a little fatter, up from 29% to 31%. So I believe any remaining difference is explainable by failed vectorization for Paeth in the RGB case.

[workingjubilee]

Hm. If you want to use https://github.com/rust-lang/cargo-bisect-rustc with either a script or the manual prompt mode to pin down the commits that regress and un-regress this then we might be able to figure out why any more subtle changes that remain happened.

[kornelski]

The autovectoziation could be tested in CI to catch regressions sooner.

Maybe cargo-show-asm could be used to extract the relevant functions.

[Shnatsel]

The regression in autovectorization for Paeth filter has been bisected to a specific LLVM commit: llvm/llvm-project#144276