build(deps): bump https://github.com/astral-sh/ruff-pre-commit from v0.16.10 to 0.17.0 - #9225

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

• Autofix · 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 not alter performance

✅ 62 untouched benchmarks
⏩ 4 skipped benchmarks¹

_{Comparing dependabot/pre_commit/https-/github.com/astral-sh/ruff-pre-commit-0.17.0 (8ebc561) with main (eb2ffc6)}

@codspeedbot explain regression

@codspeedbot explain regression

The regression isn't real. This PR doesn't touch any code that runs in the benchmark, and the extra time comes from a single glibc allocator cleanup pass.

This PR only changes config. The diff is one line in .pre-commit-config.yaml, bumping the ruff pre-commit hook. None of that is compiled into the benchmark binaries, so the RustPython code measured here is the same on main (eb2ffc6) and this branch (8ebc561).

Where the extra ~55 µs goes. I compared the flamegraphs of rustpython[frozenset.py] on both runs:

RustPython's own functions cost the same on both runs. The whole difference is one malloc_consolidate pass in glibc, triggered while the frozensets and ints are freed when the module dict is torn down. Whether that pass lands inside the measured iteration depends on the heap's state beforehand. That state varies between runs because each benchmark process gets a random string hash seed (hash_seed = None in benches/microbenchmarks.rs). This benchmark has switched between about 357 µs and 411 µs this way before, including on PRs #8979 and #9011.

The "different runtime environments" warning also applies to this benchmark, since the two runs linked different system libraries. That is another reason not to trust a 13% move on its own here.

What to do: you can acknowledge the regression on CodSpeed and merge the bump. If you want this flake gone for good, setting a fixed hash_seed (for example Some(0)) in the microbenchmark harness would make heap layout repeatable from run to run.

Comment @codspeedbot pin the hash seed in the microbenchmark harness and I'll open a PR for it.

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

@codspeedbot is the hash seed already pinned in the microbenchmark harness?

@codspeedbot is the hash seed already pinned in the microbenchmark harness?

Yes, it's already pinned, and my earlier comment was wrong about that. Sorry for the bad suggestion.

benches/microbenchmarks.rs has set settings.hash_seed = Some(0) since #9126 (ba54cce, merged 2026-10-15). Both main (eb2ffc6) and this PR (8ebc561) include that commit. The hash secret is process-wide and the first interpreter sets it, so every microbenchmark interpreter uses seed 0. Also, frozenset.py only hashes ints, and int hashes don't use the string hash secret at all. So the hash seed can't explain this result, and you don't need a PR to pin it.

What still holds:

• This PR doesn't change any benchmarked code. It only edits .pre-commit-config.yaml.
• main is stable on this benchmark. rustpython[frozenset.py] measured 358.4, 358.1, 358.0 and 357.8 µs on the last four main runs (c08375b, eb2ffc6, 58b54c4, 073136a). This PR's 413.6 µs is a single outlier.
• The extra ~55 µs is all in glibc. It comes from a malloc_consolidate / unlink_chunk pass during teardown. RustPython's own functions cost the same on both runs.
• The two runs used different environments. CodSpeed's comparison flags different linked libraries for this benchmark between the base and head runs, which is a likely cause of the allocator-state difference.

The conclusion is the same as before: this is noise, not a regression. You can acknowledge it on CodSpeed and merge the bump.

Comment @codspeedbot rerun the comparison after a rebase if you'd like me to check whether the outlier repeats.

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

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