Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Merging this PR will degrade performance by 1.8%

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 60 untouched benchmarks
⏩ 4 skipped benchmarks¹

Performance Changes

_{Comparing dependabot/cargo/bitflags-2.13.2 (e3a0409) with main (3e0e401)}

@codspeedbot explain performance differences

@codspeedbot explain performance differences

Neither change comes from the bitflags bump

The PR only touches Cargo.lock (bitflags 2.13.1 → 2.13.2). The upstream change (bitflags#496) only moves const declarations around inside the macro expansion. It doesn't change how flags behave at runtime, and none of the RustPython code that got slower or faster goes through bitflags.

❌ rustpython[frozenset.py]: 357.5 µs → 411.9 µs (-13%)

• On main this benchmark doesn't move: about 357.5 µs on each of the last 4 commits, and 358.0 µs on the similar lockfile-only PR build(deps): bump which from 8.0.5 to 8.0.6 #8978.
• Comparing the two flamegraphs, almost the whole +54 µs is one call to glibc's malloc_consolidate (53.2 µs), which appears only in this PR's run. It happens during teardown, when the frozenset's large entry table is freed (default_dealloc::<PyFrozenSet> → Arc<Dict<()>>::drop_slow: 139.8 → 183.5 µs).
• glibc runs malloc_consolidate when a large block is freed while some small freed blocks are still waiting to be merged. Whether that happens depends on the state of the process heap, which depends on what ran earlier in the same process. It doesn't depend on RustPython's code. The RustPython frames (PySetInner::hash, default_dealloc::<PyInt>, etc.) cost the same in both runs.

⚡ rustpython[loop_string.py]: 936.6 µs → 842.9 µs (+11%)

• Here the baseline was a slow run. Over recent main commits this benchmark reads between roughly 844 and 937 µs, and 842.9 µs sits at the normal end of that range.
• The swing comes from dict lookups. The microbenchmark harness uses Settings::default(), so every run picks a random string hash seed. That changes how many probes dict lookups take on the globals dict from run to run.

"Different runtime environments" warning

CodSpeed saw different linked libraries on the two runs: the base run recorded no linked-library info, and this PR's run lists libpython, libffi and libm. That's a difference in the CI environment, and a Cargo.lock bump can't cause it.

Recommendation

You can safely acknowledge both results on CodSpeed and merge. To reduce this noise on future PRs, the microbenchmark harness could set a fixed hash seed (settings.hash_seed = Some(0) in benches/microbenchmarks.rs). That makes the hash-dependent dict behaviour repeatable. The malloc_consolidate effect could still show up occasionally, because it depends on heap state rather than on the seed.

I didn't change any code on this PR.

Full comparison

_{Learnings updated. See what CodSpeed remembers about this repository.}

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}