`slice::contains` runtime doubles when an unrelated `binary_search` benchmark is present

[Gourab-Ghosh]

Summary

On my machine, the runtime of slice::contains in a tight loop changes drastically (~2×) depending on whether an additional, unrelated benchmark using slice::binary_search is present in the same binary. The contains benchmark is executed before the binary_search benchmark, but still becomes much slower when the third benchmark is compiled/executed afterwards.

This looks like a codegen/layout/inlining interaction (or similar), not a source-level change to the contains call.

---

Reproduction

Command

cargo run --release

Repro code (src/main.rs)

#![allow(unused)]

use PieceType::*;
use std::hint::black_box;
use std::time::Instant;

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Clone, Copy)]
enum PieceType {
    Pawn,
    Knight,
    Bishop,
    Rook,
    Queen,
    King,
}

macro_rules! benchmark {
    ($code:block, $num_iterations:expr $(,)? ) => {{
        let now = Instant::now();
        for _ in 0..$num_iterations {
            black_box($code);
        }
        println!("Time taken to run: {:?}", now.elapsed());
    }};
}

fn main() {
    let num_iterations: usize = 25_000_000_000;

    benchmark!(
        { matches!(Pawn, Knight | Bishop | Rook | Queen) },
        num_iterations,
    );
    benchmark!(
        { const { [Knight, Bishop, Rook, Queen] }.contains(&Pawn) },
        num_iterations,
    );
    benchmark!(
        {
            const { [Knight, Bishop, Rook, Queen] }
                .binary_search(&Pawn)
                .is_ok()
        },
        num_iterations,
    );
}

Observed output (with binary_search benchmark present)

Time taken to run: 4.700495676s
Time taken to run: 10.036953544s
Time taken to run: 4.750905003s

---

Control case

Comment out the last benchmark!( ... binary_search ... ) block (no other changes), then run the same command.

Observed output (without binary_search benchmark)

Time taken to run: 4.819309506s
Time taken to run: 4.75536901s

---

Expected

The second benchmark (const { [Knight, Bishop, Rook, Queen] }.contains(&Pawn)) should have comparable runtime regardless of whether a later, unrelated benchmark is present.

Actual

contains becomes ~2× slower only when the binary_search benchmark exists in the same program.

---

Environment

Hardware (Lenovo Legion Pro 7i Gen 10, 2025)

• CPU: Intel Core Ultra 9 275HX
• RAM: 64 GB DDR5-6400
• GPU: NVIDIA GeForce RTX 5070 Laptop GPU

Software

• OS: Garuda Linux (Arch-based), x86_64
• Rust Version: rustc 1.92.0 (ded5c06 2025-12-08) (Arch Linux rust 1:1.92.0-1)
• Build/run: cargo run --release

[lukaslueg]

This is an error in observation. The benchmarks do not measure anything.

As stated above, the benchmarks compile to empty loops. The black_box($code) does not help, as the compiler does evaluate $code before black_box() has any effect on it; you'll need to move/add the application of black_box() to e.g. surrounding the parameters entering the comparison.

The first loop is completely removed, you're measuring the time it takes to count to 25m; the second loop is almost completely removed; the third loop reuses the result of the second loop. This is why it appears that the third loop is making the second loop slower; if you remove the third loop, everything except counting to 25m twice is removed.

[saethlin]

That being said, the deoptimization is real. Probably IPSCCP?

[Gourab-Ghosh]

@lukaslueg Thanks for pointing out that I had been using black_box incorrectly. But since @saethlin says that there is an optimization issue, I will keep the issue open.

[Morgane55440]

i tried, but was unable to reproduce the slowdown reliably.

they produce the exact same code in godbolt (just decrementing a register 25 billion times), therefore i believe the perceived slowdown is more likely to be due to thread scheduler sheninigans.

what is absolutely certain is there is nothing for the rust compiler to do here(the loops where completely optimized), therefore i would advise that this issue be closed.

godbolt link

[Morgane55440]

@saethlin i see you have reopened the issue. i'm sorry i didn't try to get your opinion before giving mine.

you mentioned that "the deoptimization is real". have you been able to reproduce the issue ?

have you seen bad asm ? maybe it's on a specific target different from what i used in godbolt.

you mentioned the Interprocedural Sparse Conditional Constant Propagation Pass, but all the constant got properly propagated in the asm, so that didn't really make sense to me,

which is why i assumed it was just a theory you had simply looking at the code to make sense of the result. sorry again

@Gourab-Ghosh if you could provide your precise target triple maybe we could check the corresponding asm to be extra safe.

you could also run both versions a couple times to see if they do have consistent results.

if you put your code in a file test.rs, you can run rustc -Copt-level=3 --emit asm test.rs to check the asm yourself.

the loop are easy recognizable with the 25000000000 litterals

[saethlin]

Calm down. This is just a GitHub issue, things move slowly. I reopened this because I have been slowly adding to this reply as I work on it.

You are right that it doesn't reproduce anymore. I've bisected, and it reproduces reliably until c7aa99f. Try with toolchains up to and including nightly-2025-12-27 and you'll see the effect. Alternatively, check the codegen for beta and the latest stable (1.92.0) in godbolt.

There is a flag in LLVM to disable IPSCCP, but I need to build a custom toolchain to use it: #t-compiler/llvm > Flag to disable IPSCCP?

I'm going to try to use that flag to confirm that IPSCCP is responsible for this scenario, then think about what to do if it is because this would be the nth time someone has filed an issue like this.

[Morgane55440]

Calm down. This is just a GitHub issue, things move slowly.

sry about that