GH-139951: Fix major GC performance regression by markshannon · Pull Request #140262 · python/cpython

@markshannon

* Count number of actually tracked objects, instead of trackable objects. This ensures that untracking tuples has the desired effect of reducing GC overhead
* Do not track most untrackable tuples during creation. This prevents large numbers of small tuples causing execessive GCs.

@markshannon

eendebakpt

sergey-miryanov

sergey-miryanov

sergey-miryanov

efimov-mikhail

sergey-miryanov

sergey-miryanov

sergey-miryanov

efimov-mikhail

@markshannon

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request

Oct 21, 2025
* Count number of actually tracked objects, instead of trackable objects. This ensures that untracking tuples has the desired effect of reducing GC overhead

* Do not track most untrackable tuples during creation. This prevents large numbers of small tuples causing execessive GCs.
(cherry picked from commit 0c01090)

Co-authored-by: Mark Shannon <mark@hotpy.org>

markshannon added a commit that referenced this pull request

Oct 23, 2025
…-140262 (GH-140447)

* Count number of actually tracked objects, instead of trackable objects. This ensures that untracking tuples has the desired effect of reducing GC overhead
* Do not track most untrackable tuples during creation. This prevents large numbers of small tuples causing execessive GCs.

This was referenced

Oct 25, 2025

nascheme added a commit to nascheme/cpython that referenced this pull request

Nov 27, 2025
This reverts parts of the pythonGH-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
bug pythonGH-139951 is still resolved (work_to_do changes are not required).

This was referenced

Nov 27, 2025

StanFromIreland pushed a commit to StanFromIreland/cpython that referenced this pull request

Dec 6, 2025
* Count number of actually tracked objects, instead of trackable objects. This ensures that untracking tuples has the desired effect of reducing GC overhead

* Do not track most untrackable tuples during creation. This prevents large numbers of small tuples causing execessive GCs.

sergey-miryanov pushed a commit to sergey-miryanov/cpython that referenced this pull request

Jan 24, 2026
This reverts parts of the pythonGH-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
bug pythonGH-139951 is still resolved (work_to_do changes are not required).

sergey-miryanov pushed a commit to sergey-miryanov/cpython that referenced this pull request

Jan 25, 2026
This reverts parts of the pythonGH-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
bug pythonGH-139951 is still resolved (work_to_do changes are not required).