| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
* 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.
if (gcstate->work_to_do < 0) {
return;
}
|
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
There was a problem hiding this comment.
Code looks good to me, thanks!
Sorry, something went wrong.
|
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). |
Sorry, something went wrong.
|
Thanks @markshannon for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14. |
Sorry, something went wrong.
* 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>
|
GH-140423 is a backport of this pull request to the 3.14 branch. |
Sorry, something went wrong.
…-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).
| Back | FazBrowse Home | New Git URL |
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.