> So all those instances have an increase in memory footprint compared to Python 3.7 ?
I am afraid that's the case. This is one of the costs of making types not being heap types. On Thu, 27 May 2021, 19:04 Marc-Andre Lemburg, <m...@egenix.com> wrote: > On 27.05.2021 19:40, Tim Peters wrote: > > [Pablo Galindo Salgado <pablog...@gmail.com>] > >> Hi Marc, > >> > >> Yes, check out this from the 3.9 what's new document: > >> > >> https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api > >> > >> Instances of heap-allocated types (such as those created with > PyType_FromSpec() > >> and similar APIs) hold a reference to their type object since Python > 3.8. > >> ... > > Thanks for these details. I wasn't aware of that change. > > So all those instances have an increase in memory footprint > compared to Python 3.7 ? > > > I think Marc-Andre's question is more subtle than that: > > > > [Marc-Andre Lemburg, <m...@egenix.com>] > >>> Hi Pablo, > >>> > >>> could you or Erlend please explain why types which don't reference > >>> any other objects need to participate in GC for deallocation ? > > ... > >>> AFAIK (but could be wrong, of course), the type object itself > >>> does not reference any other objects related to the object > >>> that is being GCed. > > > > To make that more formal, if there's a chain of pointers from an > > object X that reaches X again (X is a direct member of a cycle), then > > for cyclic gc to work X's tp_traverse must visit all directly > > contained objects that could be the second object in a direct cycle > > reaching X again. > > > > But, for example, if X contains a tuple of integers, there's no need > > for X's tp_traverse to visit that tuple. It's impossible to reach X > > from the tuple. Cyclic gc cares only about cycles; chasing non-cyclic > > dead ends doesn't accomplish anything beyond burning processor cycles. > > > > This is, I believe, akin to what Marc-Andre is bringing up: if X > > can't be reached _from_ X's type object, there's no need for X's > > tp_traverse to visit X's type object. It _can_ be visited, but it > > would be a waste of time. > > Indeed, that's what I was after. GC is really only needed for > objects which can potentially participate in cycles which need > to be reclaimed. As I understand the logic (even with the objects > referencing the constant type objects on the heap), many of the > objects which are now made GC traversal aware don't really have > a need for it -- their traversal only finds type objects, no > other objects. > > >>> ... > >>> By having (nearly) all stdlib types participate in GC, even ones > >>> which don't reference other objects and cannot be parts of reference > >>> circles, instead of immediately deleting them, we will keep those > >>> objects alive for much longer than necessary, potentially causing a > >>> resource overhead regression. > > > > But I think "waste of time" is the worst of it. Participating in > > cyclic gc does nothing to delay refcounting from recycling objects > > ASAP. gc only reclaims objects that are reachable only from dead > > cycles; everything else in CPython is reclaimed the instant its > > refcount falls to 0, and that's so regardless of whether it > > participates in cyclic gc. > > Oh, thanks for the explanation. I was under the impression that > GC-aware objects are added to a GC pool for processing at the > next GC run. If that's not the case in general -- only if they > are part of dead cycles -- then it's merely wasting time on > traversing known dead ends... and developer time for adding the > unnecessary logic ;-) > > Perhaps this provides an easy way to unblock the release :-) > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, May 27 2021) > >>> Python Projects, Coaching and Support ... https://www.egenix.com/ > >>> Python Product Development ... https://consulting.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > https://www.egenix.com/company/contact/ > https://www.malemburg.com/ > >
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q7AT6AY3CUT5SUKF6TSWP5VK5NVTKBNR/ Code of Conduct: https://www.python.org/psf/codeofconduct/
