| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
I'm not sure that this needs a NEWS entry because it is an implementation detail. But I'm here on triage/core decision. |
Sorry, something went wrong.
|
Sorry, misclick. |
Sorry, something went wrong.
|
PyTuple_Pack is user-facing, so let's add a blurb. |
Sorry, something went wrong.
|
Which cases would benefit from this change to PyTuple_Pack? We could apply a similar optimization to some other methods to construct a tuple (e.g. _PyTuple_FromArray, or inside dictiter_iternextitem), and it is not clear to me directly which ones would benefit (no gc tracking), and which ones would not (expensive to check all the arguments) PyTuple_Pack itself is slow (due to varargs), so there should not be a lot of cases where this is used often. Note: I used this code to check which cases are impacted import gc
import random
a = (1, 2, 3, 4)
b = tuple([1,2,3])
c = tuple(list([1,2,3]))
d = (2,3) * (random.randint(2, 4)+2)
print(f'{gc.is_tracked(a)=}') # still tracked
print(f'{gc.is_tracked(b)=}')
print(f'{gc.is_tracked(c)=}')
print(f'{gc.is_tracked(d)=}')
d={10: 1, 11: 2}
one_dict_item = next(iter(d.items()))
print(f'{gc.is_tracked(one_dict_item)=}') # still tracked!
l=[]
l.extend(d.items())
print(f'{gc.is_tracked(l[0])=}') # here it works! l[0] is not tracked
for tp in d.items():
print(f'{gc.is_tracked(tp)=}') # tracked, even though this might be a common use case
|
Sorry, something went wrong.
|
@eendebakpt Yeah, I did the same for:
Collecting stats and microbenchmarking now. |
Sorry, something went wrong.
|
Tests fail because instrumentation a bit straightforward and work on my machine |
Sorry, something went wrong.
|
Tests will fail because I write stats to stderr. |
Sorry, something went wrong.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
When we use PyTuple_Pack all 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.