build(deps): bump the wasmtime group across 1 directory with 3 updates - #8971

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.

• 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 improve performance by 16.36%

⚡ 2 improved benchmarks
✅ 60 untouched benchmarks
⏩ 4 skipped benchmarks¹

Performance Changes

_{Comparing dependabot/cargo/wasmtime-7f32c4007c (2a1fbe5) with main (bbb0f78)²}

@codspeedbot explain why performance improved

@codspeedbot explain why performance improved

Short answer: this PR doesn't make anything faster. The +16% is noise from the baseline run, not a change in the code being benchmarked.

Why the bump can't change these numbers

• Only the cranelift, cranelift-jit and cranelift-module versions change (Cargo.toml / Cargo.lock). The only crate that uses them is rustpython-jit, and that is only built with the optional jit feature, which is off by default.
• The CodSpeed workflow builds with cargo codspeed build -p rustpython -p rustpython-sre_engine and default features. cargo tree -p rustpython -i cranelift finds no cranelift in that dependency graph. The benchmark binaries are built from the same code with or without this PR.

Where the difference comes from

• The report compared against an older base (bbb0f78), because no finished run existed yet for the newer main commit. That base was on the slow side of a known swing:

Compared against the newer main run (1269277), neither benchmark changes (comparison).

• These two benchmarks are known to jump between about 40.7/47.6 ms and about 843/995 µs between runs of the same code. Both loop over a string at module level (for char in s: pass), so every iteration stores the loop variable into the globals dict. benches/microbenchmarks.rs uses Settings::default(), so each benchmark process picks a random string hash seed. That changes how long dict lookups take in that loop and how memory is laid out, which moves the cache-miss part of the simulated time. The same swing has shown up on other PRs that didn't touch the VM.
• The two runs also used different CPUs (EPYC 9V74 for the base, EPYC 7763 for the head), which CodSpeed flags as "different runtime environments". That adds more variation to the cache model.

If you want these benchmarks to be stable

Setting a fixed seed in the microbenchmark harness, e.g. settings.hash_seed = Some(0) in benches/microbenchmarks.rs, should stop this dict-related swing. Comment @codspeedbot add a fixed hash seed to the microbenchmark harness and I'll open that change.

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