build(deps): bump insta from 1.48.0 to 1.49.0 - #9224

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/cargo/insta-1.49.0 (294fb90) with main (c08375b)}

@codspeedbot explain why performance improved

@codspeedbot explain why performance improved

In short, this PR doesn't make anything faster. The +10% on parse_to_ast::rustpython[richards.py] is measurement noise from heap state, not an effect of the insta bump.

The PR can't change the benchmark binary

The only file changed is Cargo.lock:

• insta 1.48 → 1.49 is a dev-dependency of rustpython-stdlib only. cargo tree -i insta on the rustpython package (normal, build and dev edges, Linux target) finds nothing.
• The other changed lines (windows-sys 0.61 → 0.52, and tempfile switching to getrandom 0.3) only apply to Windows targets or to tempfile, which is not in the bench dependency graph either.

So the Linux benchmark binary is built from the same code as on main.

Where the 0.17 ms comes from

Comparing the base flamegraph (eb2ffc6) with the head one (0e9fa62):

All of the gain is inside glibc's allocator: realloc grew blocks in place more often, and fewer frees triggered consolidation. The parser itself did the same amount of work.

Why the allocator behaves differently from run to run

benches/execution.rs runs every benchmark in a single process, in HashMap order. The heap state left behind before parse_to_ast[richards.py] starts therefore changes between runs. Recent main commits show the same benchmark moving with no parser changes:

The base happened to be one of the slow samples. Compared with the next main run, the difference is about 4%, well inside the usual spread. All the other benchmarks in this PR are unchanged. Nothing here needs action, and the bump is fine to merge as far as performance goes.

To make these results stable, the benches could run in a fixed order (for example a BTreeMap instead of a HashMap in execution.rs), or parse_to_ast could run in its own process. Comment @codspeedbot make the execution benchmarks run in a deterministic order if you want me to open a PR for that.

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

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

@codspeedbot pin the hash seed in the execution benchmark harness

@codspeedbot pin the hash seed in the execution benchmark harness

I pinned the hash seed in the execution benchmark harness and pushed the change to this branch as adec249.

Change

In benches/execution.rs, bench_rustpython_code now sets the same seed that benches/microbenchmarks.rs already uses:

// Pin the str/bytes hash secret so dict/set probe sequences (and thus
// timings) are reproducible across benchmark runs.
settings.hash_seed = Some(0);

Every RustPython interpreter in this harness is created by that function. The hash secret is set once per process by the first interpreter, so all pystone and execution benchmarks now hash str/bytes the same way on every run.

Checks

• cargo check --bench execution passes.
• execution/nbody.py runs successfully in criterion test mode. I didn't run a full CodSpeed run locally; this PR's CI run will measure the change.

Caveats

• This won't stabilise parse_to_ast::rustpython[richards.py], the benchmark that showed +10% here. It only runs the ruff parser and never hashes Python objects. Its swings come from the heap state left by earlier benchmarks, which depends on the HashMap iteration order in criterion_benchmark. Running the benchmarks in a fixed order (e.g. a BTreeMap) would address that.
• This adds a benchmark-harness change to a Dependabot PR, so Dependabot will no longer rebase this branch automatically. If you'd rather keep the bump separate, the change can be cherry-picked into its own PR.

Comment @codspeedbot make the execution benchmarks run in a deterministic order and I'll make that change too.

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

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

@codspeedbot open a separate PR with the previous commit

@codspeedbot open a separate PR with the previous commit

I opened #9235 with the hash-seed commit (adec249) on top of current main. It contains only the 3-line change in benches/execution.rs that sets settings.hash_seed = Some(0), and cargo check --bench execution passes.

The commit is still on this Dependabot branch too. I didn't remove it because that means force-pushing here. To get back to a clean bump, comment @dependabot recreate, or ask me with @codspeedbot drop the hash-seed commit from this PR.

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

@dependabot recreate