GeezerVison

reviews:
  auto_review:
    drafts: true

• 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.

📦 Library Dependencies

The following Lib/ modules were modified. Here are their dependencies:

[x] lib: cpython/Lib/profile.py
[x] test: cpython/Lib/test/test_profile.py
[x] test: cpython/Lib/test/test_profiling/test_tracing_profiler.py

dependencies:

• profile

dependent tests: (1 tests)

• profile: test_profile

[ ] test: cpython/Lib/test/test_free_threading (TODO: 1)

dependencies:

dependent tests: (no tests depend on free_threading)

Legend:

• [+] path exists in CPython
• [x] up-to-date, [ ] outdated

Merging this PR will degrade performance by 19.03%

❌ 23 regressed benchmarks
✅ 39 untouched benchmarks
⏩ 4 skipped benchmarks¹

Performance Changes

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

_{Comparing youknowdot:youknowdot/free-threading-remaining-batch-315-20261028 (2845454) with main (05daf00)}

hmm, let's check performance before merge

@codspeedbot explain performance drop

hmm, let's check performance before merge

@codspeedbot explain performance drop

Why performance dropped

This is a real regression, not noise. All of it comes from f8a7823 ("Keep monitoring dispatch in interpreter-local state"):

• The run for c672599 (dict/CSV/mmap/syslog changes) matches main.
• Comparing c672599 → f8a7823 shows the same 24 regressions (−10% to −25%) as the PR report.
• The regressions cover every interpreter-heavy benchmark (nbody, generators, pystone, richards, fannkuch, the microbenchmarks). That pattern points to a cost paid on every bytecode instruction.

What the flamegraph shows (nbody.py, Simulation)

The float, list and call code costs the same in both runs (e.g. default_dealloc<PyFloat> 67.9 → 67.2 ms, PyFloat::into_ref 31.7 → 31.8 ms). The added time is all overhead in the dispatch loop, even though no monitoring tool is active.

Where it comes from in the code

1. A function call before every instruction (crates/vm/src/frame.rs:3909):

   let mut virtual_dispatch = if PREPARE_GENERATOR { None }
       else { monitoring::dispatch_operation(vm, self.code, idx) };

   dispatch_operation (sys/monitoring.rs:718) is not inlined. Even its fast path (vm.state.monitoring_events.load() == 0) costs a call, a pointer chase through vm.state and an atomic load per instruction. It also returns an Option<(MonitoringInstruction, Instruction)> that the loop then branches on. On main, the loop goes straight to read_unit_from. This adds extra live values in the hottest loop, which also explains why the loop's own self time grew by ~45%.

2. Extra writes per instruction in execute_instruction (frame.rs:4665-4666):

   let index = self.lasti().saturating_sub(1);
   self.monitoring_previous = self.monitoring_current.replace(Some(index));

   This re-loads lasti, even though the loop already holds idx, and writes two Option<u32> frame fields on every instruction, monitored or not.

3. Smaller additions: the virtual_line/legacy_line_processed checks and the DispatchMode/caches tuple on the decode path. Each one is cheap, but they all sit in the loop.

Ways to recover it

• Make the disabled case close to free. Split dispatch_operation into an #[inline(always)] check on monitoring_events == 0 and a #[cold] #[inline(never)] slow path. Better still, follow CPython: check instrumentation only at RESUME, backward jumps or the eval breaker, and keep a frame-local "monitored" flag. The plain path would then match main.
• Track monitoring_previous/monitoring_current only in monitored mode, and take the index from idx instead of re-loading lasti. If the generator-close LINE fix (f1c31d7) needs the previous position in the normal path too, it could be saved only when a frame suspends instead of on every instruction.
• Re-run the benchmarks after either change. A plain path that matches main should bring these benchmarks back to their baseline.

I haven't changed any code on the branch. Comment @codspeedbot try making the monitoring fast path zero-cost when no tool is active and I'll prototype the fix and benchmark it.

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

TODO: need review