-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
GH-139951: Fix major GC performance regression #140262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* 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.
|
I'm not sure I get what android (x86_64) fails.
|
|
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. |
There was a problem hiding this 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!
|
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). |
Misc/NEWS.d/next/Core_and_Builtins/2025-10-17-18-03-12.gh-issue-139951.IdwM2O.rst
Outdated
Show resolved
Hide resolved
|
Thanks @markshannon for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14. |
* 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]>
|
GH-140423 is a backport of this pull request to the 3.14 branch. |
…-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 PR:
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.