>> >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 way to avoid the behaviour I'm sure the development >team would be interested to hear it :-)
> >I think you'll find that most programs that eat through memory in this >way will exhibit pretty much the same behaviour. If you *know* your >program isn't creating data cycles, just turn the GC off and rely on >reference counting. That won't save you from paging when you eventually >exhaust physical memory. Nothing can. Could you clarify that for me. GC really has three components two it: 1) finding and freeing unrefernced memory by refer counts 2) cycle removal and 3) defragementing the storage stack. If I turn off GC, don't I lose all of these? >From a user perspective, turning off GC and then managing it yourself is >unappealing. What would be preferrable would be to be able to simply turn >down it's threshold. That is, what I really want is to tell GC it can hold >off and checks other than reference counts until X% of the memory is filled. >At some point I want it to kick in, and I don't want to have to >programatically manage that, but simply specify a simple tolerance. Even better , I'd like to keep 1 and 3 and turn off just 2 and just use weak reference in the few cases I really need them. -- http://mail.python.org/mailman/listinfo/python-list
