| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM! I think we should apply the same kind of optimization to the free-threaded GC. I can do that, unless you want to.
Sorry, something went wrong.
There was a problem hiding this comment.
One small nit, otherwise looks good to me!
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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.