Neil Schemenauer wrote:
BTW, I suspect that documentation needs updating since I understand
that the GC is no longer optional (the stdlib and/or the Python
internals create reference cycles themselves).
Is it possible and might it be useful for those internal cycle-creating
operations to in
>>> Wouldn't it be simpler just to base the collection frequency
>>> directly on the total number of objects in the heap?
>>
>> Using what precise formula?
>
> The simplest thing to try would be
>
> middle_collections >= num_objects_in_heap * some_constant
So what value is some_constant?
Regar
Martin v. Löwis wrote:
Wouldn't it be simpler just to base the collection frequency
directly on the total number of objects in the heap?
Using what precise formula?
The simplest thing to try would be
middle_collections >= num_objects_in_heap * some_constant
--
Greg
___
> Another problem is that the program could be slowly leaking and a
> full collection will never happen.
I don't think that will be possible. If the program slowly leaks,
survivor objects leave the middle generation, and account towards
the 10%. As the count of objects in the oldest generation doe
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
>
>> Under my proposal, 10 middle collections must have passed,
>> PLUS the number of survivor objects from the middle generation
>> must exceed 10% of the number of objects in the oldest
>> generation.
>
> What happens if the program e
Greg Ewing canterbury.ac.nz> writes:
>
> What happens if the program enters a phase where it's not
> producing any new cyclic garbage, but is breaking references
> among the old objects in such a way that cycles of them
> are being left behind? Under this rule, the oldest
> generation would never
> What happens if the program enters a phase where it's not
> producing any new cyclic garbage, but is breaking references
> among the old objects in such a way that cycles of them
> are being left behind? Under this rule, the oldest
> generation would never be scanned, so those cycles would
> neve
Martin v. Löwis wrote:
Under my proposal, 10 middle collections must have passed,
PLUS the number of survivor objects from the middle generation
must exceed 10% of the number of objects in the oldest
generation.
What happens if the program enters a phase where it's not
producing any new cyclic
If you can get me a version of the interpreter with this change made
(I wouldn't know what to change), I can run a very
allocation/deallocation-heavy application I have lying around, and get
you some good benchmarks.
On Sat, Jun 21, 2008 at 1:23 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
- S
On Sat, Jun 21, 2008 at 1:23 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Here is my proposal for making the GC run less often.
> The objective is to avoid the quadratic-time behavior
> if many objects are created and none of them is garbage.
>
[SNIP]
> Applications with a small number of obj
Here is my proposal for making the GC run less often.
The objective is to avoid the quadratic-time behavior
if many objects are created and none of them is garbage.
The youngest generation remains collected after 700
allocations, the middle generation after 10 young collections.
Therefore, full GC
11 matches
Mail list logo
