Is this a bug? Python intermittently stops dead for seconds
cems at earthlink.net
Sun Oct 1 18:19:45 CEST 2006
On Oct 1, 2006, at 9:48 AM, Fredrik Lundh wrote:
> charlie strauss wrote:
>> level0: newly created objects
>> level1: objects that survived 1 round of garbage collection
>> level2: objects that survivied 2+ rounds of gargbage collection
>> Since all of my numerous objects are level2 objects, and none of
>> them are every deallocated, then I should never trip the GC for
> your understanding of generational GC is a bit fuzzy, it seems.
> that an
> object is promoted to a higher level means that it's not inspected
> as often as lower-level objects, not that it's never inspected at all.
As I understand it, level2 (and level1) objects only undergo gc when
more than 10 of them is deallocated. Since I never deallocate, this
should not be tripped right?
In any case regarding your other comments:
>> Could you clarify that for me. GC really has three components
>> two it: 1) finding and freeing unrefernced memory by refer
>> refer counts 2) cycle removal and 3) defragementing the
>> storage stack. If I turn off GC, don't I lose all of these?
> CPython always does (1), only does (2) if cycle-breaking GC isn't
> disabled, and never does (3).
Never does 3? then how does it compact it's memory allocation area?
Surely it does not rely on the OS to manage every small object as a
separate memory allocation.
And just to be clear: are you saying that when I do a gc.disable this
only turns off 2 and not 1? The docs don't say that as far as I can
> in your case, it's (2) that takes more and more time, simply because
> you're creating tons of non-trivial objects. to see what's going
> on in
> there, add
> import gc
> to the top of your program, and look at the status messages that
> just before each "Big Gap" message.
Could you be a bit more explicit. I'm new to the gc module. Sorry
to be slow but I don't know what "looking at the status message" means.
More information about the Python-list