A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-January/059420.html below:

[Python-Dev] Real time behaviour of Pythons memory management; WAS: RE: Documentation about Python's GC,python-dev list messages referenced in Modules/gcmodule.c notreachable anymore

[Python-Dev] Real time behaviour of Pythons memory management; WAS: RE: Documentation about Python's GC,python-dev list messages referenced in Modules/gcmodule.c notreachable anymore"Martin v. Löwis" martin at v.loewis.de
Thu Jan 5 00:45:34 CET 2006
Weber, Gregoire wrote:
> Questions
> ---------

Notice that this article is not appropriate for python-dev.
If you ask "is it the case that Python behaves such and such?",
you have a python-list (comp.lang.python) question. For
python-dev, the question should be formulated as "because
it is such and such, would it be acceptable to change it
so and so?"

> 1. Am I correct that in a system which instantiates a lot*) 
>    of containerish objects without destructing them again the 
>    GC may be triggered to evaluate all generations which may 
>    be very costy (see above)?

Correct.

> 2. In a system where only generation 0 and 1 get evaluated
>    (because not so much object got instantiated without beeing 
>    destructed) the costs are relatively low. Correct?

Correct. If the objects are *really* short-lived, a generation
0 collection might never get initiated, even though millions
of containers are created.

Regards,
Martin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4