Barry A. Warsaw
Mon, 29 Apr 2002 18:26:11 -0400
>>>>> "GvR" == Guido van Rossum <firstname.lastname@example.org> writes:
GvR> The current thresholds are used to count the number of
GvR> allocations. Adding the number of deallocations to mix seems
GvR> dangerous: when (nearly) all data is tied up in cycles, there
GvR> may not be any deallocations. It seems hard to distinguish
GvR> between these two cases:
GvR> (a) lots of memory is allocated and kept alive for real by
GvR> (b) lots of memory is allocated and kept alive accidentally
GvR> by cycles
GvR> The zip example is a case of (a), but the same allocation
GvR> behavior could ensue from case (b). Only running the
GvR> allocator can determine which case we're seeing. I like
GvR> Tim's idea of adjusting the thresholds base upon the
GvR> effectiveness of recent collections.
Isn't this a case of "knowing your application"? IOW, you're doing
something that the gc isn't well-tuned to handle, by default. That's
why we expose the its operation through the gc module -- so you can
take explicit steps for the hotspots in your application.
Not to say we can't improve the tuning, but it'll never be perfect, so
just try to make it good enough for the most common types of
programs. Then document situations where it might not do so well.