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 a
Steve, digging into the gc docs a bit more, I think the behaviour I am seeing
is still not expected. Namely, the program I offered has no obvious place
where objects are deallocated. The way GC is supposed to work is thate there
are three levels of objects
level0: newly created objects
level
>>
>I think the point you are missing is that the garbage collector is
>triggered from time to time to ensure that no cyclical garbage remains
>uncollected, IIRC. The more data that's been allocated, the longer it
>takes the collector to scan all of memory to do its job.
>
>If you can find a w
to say 0.1 second.
This is the threshold for which the computer program flags the time it takes to
create a "foo" object. on a fast computer it should take much less than 0.1
sec.
-Original Message-
>From: charlie strauss <[EMAIL PROTECTED]>
>Sent: Oct 1, 2006 10
Steve and other good folks who replied:
I want to clarify that, on my computer, the first instance of the gap occurs
way before the memory if filled. (at about 20% of physical ram). Additionally
the process monitor shows no page faults.
Yes if you let the as-written demo program run to comp
Below is a simple program that will cause python to intermittently
stop executing for a few seconds. it's 100% reproducible on my machine.
I'd be tempted to say this is a nasty garbage collection performance
issue except that there is no major memory to be garbage collected in
this script.
