On Thu, 03 Sep 2020 18:17:12 -0000
"Brandt Bucher" <brandtbuc...@gmail.com> wrote:
> Tim Peters wrote:
> > `zip` then creates `n` 2-tuple objects, each of which lives only long
> > enough to be unpacked into `x` and `y`... With "immediate" reclamation of
> > garbage via refcounting, memory use is trival regardless of how large `n`
> > is, as CPython reuses the same heap space over & over & over, ASAP. The
> > space for each 2-tuple is reclaimed before `x-y` is computed...
>
> It's also worth noting that the current refcounting scheme allows for some
> pretty sneaky optimizations under-the-hood. In your example, `zip` only ever
> creates one 2-tuple, and keeps reusing it over and over:
>
> https://github.com/python/cpython/blob/c96d00e88ead8f99bb6aa1357928ac4545d9287c/Python/bltinmodule.c#L2623
This code is a bit concerning, it means the objects yielded by zip()
can be kept alive inside the zip instance until the next iteration:
olditem = PyTuple_GET_ITEM(result, i);
PyTuple_SET_ITEM(result, i, item);
Py_DECREF(olditem);
(in case of error during iteration, it seems this may even be worse)
And tuple allocation uses freelists for small sizes, so I'm not even
sure how useful that optimization is.
Regards
Antoine.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/TJUYG2WLT3J32NVZGATKRHJMPHZVXOV2/
Code of Conduct: http://python.org/psf/codeofconduct/
