Regression in performance (poor codegen) between 1.81 and 1.82

[tobz]

I've observed a fairly nasty performance regression when switching to 1.82 related to compression performance that appears to boil down to some very weird/suboptimal machine code being generated.

Delving into things, it looks like what was previously reasonable generated code is now turning into... well, something way less reasonable, and this results in executing a vastly higher number of instructions for the same task, in turn slowing everything down. The MVCE (mentioned below) demonstrates this behavior across at least two instruction sets (x86-64 and ARM64) and a number of different microarchitectures (AMD Zen2, Zen4, and Apple M2) and reliably shows a performance regression.

Some other folks who were helping me debug this will also be posting some more information, but the biggest initial suspect looks to be the upgrade to LLVM 19 in 1.82.

Code

The MVCE is here: https://github.com/tobz/miniz-oxide-slowdown-repro.

It's a simple program that generates a deterministic input corpus, compresses it multiple times (using flate2/miniz_oxide), and then exits. Efforts were made to try and ensure things are deterministic and mostly representative of the observed change between Rust 1.81 and 1.82.

On my environment, this all boils down to each compress operation taking ~750ms when compiled on 1.81.0 or earlier, jumping to ~1.25s per operation on 1.82.0 and later, representing a ~60% slowdown.

Version it worked on

This "worked" (ran well) on 1.81.0, 1.80.0, and 1.79.0 (as far back as I checked).

Version with regression

rustc --version --verbose:

rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1

[apiraino]

cc @nikic perhaps more insights

@rustbot label +A-LLVM +I-slow

[bobrik]

Some analysis from my end:

• flamegraph on v1.81:

• flamegraph on v1.82:

It's clear that read_u16_le stands out.

• perf annotate on v1.81:

• perf annotate on v1.82:

That's a lot of instructions! You can find them with objdump:

objdump -S --no-show-raw-insn ~/miniz-oxide-slowdown-repro.1.81 | perl -p -e 's/^\s+(\S+):\t//;' | c++filt | less

• v1.81:

    slice[pos] as u16 | ((slice[pos + 1] as u16) << 8)
movzwl 0x1ffff(%rcx,%rax,1),%eax
mov    %ax,0x48(%rsp)
                if num_probes_left == 0 {
lea    0xa(%r11),%rax
mov    %rax,0x90(%rsp)
xor    %ebx,%ebx
mov    %r11,%r10
mov    %r8d,%eax
mov    %rbp,0x10(%rsp)
mov    %rcx,0x20(%rsp)
mov    %eax,%edx
nopw   0x0(%rax,%rax,1)

• v1.82 (truncated):

    slice[pos] as u16 | ((slice[pos + 1] as u16) << 8)
movzwl -0x1(%r9,%rax,1),%eax
mov    %ax,0x40(%rsp)
lea    0x2(%r15),%rax
mov    %rax,0x280(%rsp)
and    $0x7fff,%eax
mov    %rax,0x278(%rsp)
lea    0xa(%r15),%rax
mov    %rax,0x270(%rsp)
and    $0x7fff,%eax
mov    %rax,0x268(%rsp)
lea    0x12(%r15),%rax
mov    %rax,0x260(%rsp)
and    $0x7fff,%eax
mov    %rax,0x258(%rsp)
lea    0x1a(%r15),%rax
mov    %rax,0x250(%rsp)
and    $0x7fff,%eax
mov    %rax,0x248(%rsp)
lea    0x22(%r15),%rax
mov    %rax,0x240(%rsp)
and    $0x7fff,%eax
mov    %rax,0x238(%rsp)
lea    0x2a(%r15),%rax
mov    %rax,0x230(%rsp)
and    $0x7fff,%eax
mov    %rax,0x228(%rsp)
lea    0x32(%r15),%rax
mov    %rax,0x220(%rsp)
and    $0x7fff,%eax
mov    %rax,0x218(%rsp)
lea    0x3a(%r15),%rax
mov    %rax,0x210(%rsp)
and    $0x7fff,%eax
mov    %rax,0x208(%rsp)
lea    0x42(%r15),%rax
mov    %rax,0x200(%rsp)
and    $0x7fff,%eax
mov    %rax,0x1f8(%rsp)
lea    0x4a(%r15),%rax
mov    %rax,0x1f0(%rsp)
and    $0x7fff,%eax
mov    %rax,0x1e8(%rsp)
lea    0x52(%r15),%rax
mov    %rax,0x1e0(%rsp)
and    $0x7fff,%eax
mov    %rax,0x1d8(%rsp)
lea    0x5a(%r15),%rax
mov    %rax,0x1d0(%rsp)
and    $0x7fff,%eax
mov    %rax,0x1c8(%rsp)

I'm no assembly wizard, but it seems excessive and likely the reason.

[randomairborne]

This function is not actually this issue, see hanna-kruppe's comment.

Just wanna add- [this function does claim to rely on the compiler having certain smarts](https://github.com/Frommi/miniz_oxide/blob/0a33effd414711b379e01b0613ba5ae85a0e14d0/miniz_oxide/src/deflate/core.rs#L406-L411), in case it's relevant ```rust // Read the two bytes starting at pos and interpret them as an u16. #[inline] const fn read_u16_le(slice: &[u8], pos: usize) -> u16 { // The compiler is smart enough to optimize this into an unaligned load. slice[pos] as u16 | ((slice[pos + 1] as u16) << 8) } ```

[hanna-kruppe]

The read_u16_le function appears to compile to a single movzwl in both versions (and I would have been really surprised of that optimization had regressed). The other instructions that do differ have no relation to read_u16_le and come from other parts of the source code, they just aren’t attributed to the respective source lines because debug information is very imperfect when compiling with heavy optimizations.

[dianqk]

The function miniz_oxide::deflate::core::compress_inner has doubled its instruction count, which I suspect is related.