Skip to content

Conversation

@markshannon
Copy link
Member

@markshannon markshannon commented Oct 17, 2025

This PR:

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

For the example in the original report this makes performance on main a bit better than 3.13.

Benchmarking results show this is about neutral on performance otherwise.

* 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
Copy link
Contributor

I'm not sure I get what android (x86_64) fails.
I can propose two solutions:

  1. Change default value for work_to_do from -5000 to 0
  2. Or remove newly added condition
if (gcstate->work_to_do < 0) {
    return;
}

@mhsmith
Copy link
Member

mhsmith commented Oct 19, 2025

I'm not at all familiar with the garbage collector, but one of the ways that Android differs from the other platforms is that it runs all the test suite serially in a single process.

Copy link
Contributor

@sergey-miryanov sergey-miryanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good to me, thanks!

@sergey-miryanov
Copy link
Contributor

sergey-miryanov commented Oct 21, 2025

Should we redo the benchmarks to see how the final version impacts performance? Maybe we can run it on https://github.com/faster-cpython/benchmarking-public (but I don't know how).

@markshannon markshannon merged commit 0c01090 into python:main Oct 21, 2025
45 checks passed
@miss-islington-app
Copy link

Thanks @markshannon for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

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 0c01090ad957de4625f504ce4f29df0a05d09fba)

Co-authored-by: Mark Shannon <[email protected]>
@bedevere-app
Copy link

bedevere-app bot commented Oct 21, 2025

GH-140423 is a backport of this pull request to the 3.14 branch.

@bedevere-app bedevere-app bot removed the needs backport to 3.14 bugs and security fixes label Oct 21, 2025
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants