This reverts parts of theGH-140262 change. The changes that affect the tuple untracking are left unchanged. Revert the changes to the calculation of the increment size, based on the "work_to_do" variable. This causes cyclic garbage to be collected more quickly. Revert also the change to test_gc.py, which was done because the expected GC collection was taking longer to happen.

With the tuple untrack change, the performance regression as reported by bugGH-139951 is still resolved (work_to_do changes are not required).

One way to test the effect of this change is to run the following quick-and-dirty script. It creates many reference cycles and then counts how many are not yet collected by the GC. At the end of the run, the maximum number of outstanding garbage objects are printed. With Python 3.13 (non-incremental GC), I get a max of less than 100 objects. With 3.14.0, I get approximately 2000 as the max. With the "main" branch (and 3.14 branch), I get 10,000 as the max.

gc_report_cycles.py

Issue:Incremental GC does not collect garbage as soon as expected #142002

Revert GC changes to "work_to_do" logic.

fef3eed

This reverts parts of thepythonGH-140262 change.  The changes that affect thetuple untracking are left unchanged.  Revert the changes to thecalculation of the increment size, based on the "work_to_do" variable.This causes cyclic garbage to be collected more quickly.  Revert alsothe change to test_gc.py, which was done because the expected GCcollection was taking longer to happen.With the tuple untrack change, the performance regression as reported bybugpythonGH-139951 is still resolved (work_to_do changes are not required).

Copy link

MemberAuthor

nascheme commentedNov 27, 2025•
edited
Loading

@sergey-miryanov given your recent good work on GC related things, you might want to take a look at this. This PR is an attempt at a quick fix, making the code work like the 3.14.0 release in this respect. However, for 3.15 I'm thinking we need to have a more careful look at how the GC increment size is computed. I'm going to create another PR that adds a "mark-alive" pass to the full GC run. That gives about a 2X performance improvement for full (manual) GC runs.

nascheme changed the title~~Revert GC changes to "work_to_do" logic.~~GH-142002: Revert GC changes to "work_to_do" logic.

Nov 27, 2025

bedevere-appbot mentioned this pull request

Nov 27, 2025

Incremental GC does not collect garbage as soon as expected#142002

Open

nascheme added the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section label

Nov 27, 2025

Copy link

bedevere-bot commentedNov 27, 2025

🤖 New build scheduled with the buildbot fleet by@nascheme for commitfef3eed 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F142001%2Fmerge

If you want to schedule another build, you need to add the🔨 test-with-buildbots label again.

bedevere-bot removed the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section label

Nov 27, 2025

Copy link

Contributor

sergey-miryanov commentedNov 27, 2025•
edited
Loading

@nascheme Thanks! I will take a look.
I took some measurements in September. Maybe you'll find them interesting -faster-cpython/ideas#668 (comment)

I'm comparing 3.13 and main and have following preliminary results (I have added heap_size to gcstate in 3.13):
3.13

main (and I suppose this will be the same for 3.14)

This is for benchmarks\bm_xml_etree\run_benchmark.py --worker --pipe 556 --worker-task=0 --values 3 --min-time 0.1 --loops 1 --warmups 1 --etree-module xml.etree.ElementTree run.