GeezerVison

Copy link

Copy Markdown

Member

eendebakpt reviewed Oct 17, 2025

View reviewed changes

sergey-miryanov reviewed Oct 18, 2025

View reviewed changes

sergey-miryanov reviewed Oct 18, 2025

View reviewed changes

sergey-miryanov reviewed Oct 18, 2025

View reviewed changes

efimov-mikhail reviewed Oct 18, 2025

View reviewed changes

sergey-miryanov reviewed Oct 18, 2025

View reviewed changes

if (gcstate->work_to_do < 0) {
    return;
}

markshannon requested a review from sergey-miryanov October 21, 2025 10:29

sergey-miryanov reviewed Oct 21, 2025

View reviewed changes

sergey-miryanov approved these changes Oct 21, 2025

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

efimov-mikhail approved these changes Oct 21, 2025

View reviewed changes

4 checks passed

* 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 <[email protected]>

…-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 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).

* 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 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 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).