GeezerVison

An easy win! :) The GC currently does a second reachability check because callbacks can make objects reachable again. If no weakref callback, finalizer that could run Python code, or debug writer ran, we can reuse the first result and skip that check. The finalization scan still runs. Finished generators, coroutines, and async generators use this path because their finalizers are no-ops. Free-threaded builds also skip the extra stop-the-world pause. The measurements below use a GIL-enabled build and predate the optimization for finished generators.

Microbenchmarks

Here each case uses 100,000 objects or allocation iterations. Values are median CPU milliseconds from six processes per case, with seven samples after two warmups. Explicit collections exclude graph construction.

Macrobenchmarks

A bunch of real programs tht hevily use GC. Sphinx 8.2.3 builds all CPython HTML documentation with one worker and fresh caches: 559 source files, 599 HTML files. Mypy 2.4.0 checks its own mypy and mypyc packages: 346 files, without incremental caches or workers. A separate mypy run uses --no-fast-exit, then explicitly collects its analysis graph.

Values are medians from 10 runs per executable, in baseline/candidate/candidate/baseline order. Application CPU time includes imports and command execution. GC durations come from native gc.get_stats() counters. Cleanup collections are separate from application time.

Related to #159137.

• Issue: Speed up garbage collector #159137