Uh oh!
There was an error while loading. Please reload this page.
GH-139389: Do not track immutable tuples in PyTuple_Pack - #139390
GH-139389: Do not track immutable tuples in PyTuple_Pack#139390sergey-miryanov wants to merge 6 commits into
Conversation
sergey-miryanov
commented
Sep 28, 2025
I'm not sure that this needs a NEWS entry because it is an implementation detail. But I'm here on triage/core decision. |
sergey-miryanov
commented
Sep 28, 2025
Sorry, misclick. |
ZeroIntensity
commented
Sep 28, 2025
|
eendebakpt
commented
Sep 28, 2025
Which cases would benefit from this change to
Note: I used this code to check which cases are impacted |
sergey-miryanov
commented
Sep 29, 2025
@eendebakpt Yeah, I did the same for:
Collecting stats and microbenchmarking now. |
sergey-miryanov
commented
Sep 29, 2025
Tests fail because instrumentation a bit straightforward and |
sergey-miryanov
commented
Oct 10, 2025
Tests will fail because I write stats to stderr. |
This PR is stale because it has been open for 30 days with no activity. |
When we use
PyTuple_Packall objects already well constructed. If we know that they immutable we can skip tracking it in GC, because GC will untrack them eventually.I have a PR ready and benchmark results:
Geometric mean: 1.01x faster (Win11 x64, 11th Gen Intel(R) Core(TM) i5-11600K @ 3.90GHz, 48d0d0d)
All benchmarks:
Benchmark hidden because not significant (20): 2to3, chaos, deepcopy_reduce, genshi_xml, html5lib, json_loads, nqueens, pathlib, pickle, pickle_dict, pickle_list, pidigits, regex_dna, sqlglot_normalize, sqlglot_parse, sqlglot_transpile, sqlite_synth, sympy_integrate, unpickle_list, xml_etree_generate
It doesn't hurt performance, but can decrease number of objects in GC to check and untrack.