TL;DR: This should be obvious but in case someone is worried I did my homework and this guard check has zero measurable cost and pyperformance shows 1.00x (no change). It's literally free.

This is the only place outside the profiler that has a modification, and before anyone considers if this has any effect: the answer is that it has literally zero effect. Here is how I measured it.

The guard check added to _PyEval_FrameClearAndPop compiles down to just two instructions:

278cab: cmpq   $0x0,0x50(%rdi)    ; Compare last_profiled_frame with NULL
278cb0: je     278cba             ; Jump if equal (skip the write)

During normal operation when no profiler is attached, last_profiled_frame is always NULL, which means this branch always takes the exact same path. Modern CPUs predict this perfectly after just a few iterations and never mispredict it again. A perfectly predicted branch executes speculatively with zero pipeline stalls, making it effectively free.

I confirmed this using Linux perf with hardware performance counters. I ran the Python test suite and some selected tests (test_list test_tokenize test_gc test_dict test_ast test_compile) at maximum sample rate (99,999 Hz) collecting separate data files for CPU cycles, branch mispredictions, and cache misses:

perf record -F 99999 -g -o ./perf_cycles.data -- ./python -m test 
perf record -e branch-misses -F 99999 -g -o ./perf_branch_misses.data -- ./python -m test 

First, I checked how much the entire function contributes to total CPU time:

$ perf report -i ./perf_cycles.data --stdio --sort=symbol | grep FrameClearAndPop

# Samples: 20K of event 'cpu_atom/cycles/P'
     0.10%     0.09%  [.] _PyEval_FrameClearAndPop
# Samples: 422K of event 'cpu_core/cycles/P'
     0.12%     0.10%  [.] _PyEval_FrameClearAndPop

The whole function is only 0.10% of cycles on P-cores and 0.09% on E-cores, so we're already in negligible territory. But the real question is whether the guard check causes any branch mispredictions.

I checked the function's contribution to total branch misses:

$ perf report -i ./perf_branch_misses.data --stdio --sort=symbol | grep FrameClearAndPop

# Samples: 12K of event 'cpu_atom/branch-misses/'
     0.07%     0.06%  [.] _PyEval_FrameClearAndPop
# Samples: 162K of event 'cpu_core/branch-misses/'
     0.11%     0.11%  [.] _PyEval_FrameClearAndPop

The entire function is only 0.11% of total branch misses. But within that, how much does our guard check contribute? I used perf annotate to see exactly which instructions caused branch misses within the function:

$ perf annotate -i ./perf_branch_misses.data _PyEval_FrameClearAndPop --stdio

This command reads the branch misprediction samples and maps them to specific instructions, showing what percentage of the function's branch misses occurred at each location. The result for our guard check:

; The guard check - if (tstate->last_profiled_frame != NULL)
    0.00 :   278cab: cmpq   $0x0,0x50(%rdi)   ; ← 0.00% branch misses
    0.00 :   278cb0: je     278cba            ; ← 0.00% branch misses (PERFECTLY PREDICTED)

Zero. Not a single branch misprediction was sampled at that instruction across hundreds of thousands of samples. The CPU's branch predictor correctly predicts this branch every single time because it always takes the same path.

For comparison, here's more of the annotated output showing other branches in the same function:

    0.00 :   278cb0: je     278cba    ; Guard check - 0.00% misses
   32.25 :   278cbe: jne    278d00    ; frame->owner check - 32.25% misses
   50.13 :   278cc8: call   2c39e0    ; Function call
   21.62 :   278ce5: je     278d60    ; Refcount check - 21.62% misses

The frame ownership check (frame->owner == FRAME_OWNED_BY_THREAD) accounts for 32.25% of the function's branch misses, and the refcount check (--op->ob_refcnt == 0) accounts for 21.62%. These are data-dependent branches that the CPU cannot predict perfectly. Our guard check contributes exactly 0.00% because it is perfectly predictable, unlike these other branches that depend on runtime data.

The overall Python branch miss rate is already very low (0.03% of all branches), and the guard check contributes nothing to this.

Finally, I ran pyperformance comparing main (ea51e745c713) against this PR (8d4a83894398). The geometric mean across all benchmarks is 1.00x, confirming no measurable regression in real-world workloads:

So the conclusion is that the branch is perfectly predicted, adds no memory traffic beyond reading a value already in L1 cache (tstate is hot), and avoids cache line dirtying when the profiler is not attached. Zero cost.