On Jun 22, 2017 12:38 AM, "Paul Rubin" <no.email@nospam.invalid> wrote:
Lawrence D’Oliveiro <lawrenced...@gmail.com> writes: > while “memory footprint” depends on how much memory is actually being > retained in accessible objects. If the object won't be re-accessed but is still retained by gc, then refcounting won't free it either. > Once again: The trouble with GC is, it doesn’t know when to kick in: > it just keeps on allocating memory until it runs out. When was the last time you encountered a problem like that in practice? It's almost never an issue. "Runs out" means reached an allocation threshold that's usually much smaller than the program's memory region. And as you say, you can always manually trigger a gc if the need arises. I'm with Paul and Steve on this. I've had to do a **lot** of profiling on my simulator to get it to run at a reasonable speed. Memory usage seems to follow an exponential decay curve, hitting a strict maximum that strongly correlates with the number of live objects in a given simulation run. When I draw memory usage graphs, I see sawtooth waves to the memory usage which suggest that the garbage builds up until the GC kicks in and reaps the garbage. In short, only an exceptionally poorly written GC would exhaust memory before reaping garbage. Thanks, Cem Karan -- https://mail.python.org/mailman/listinfo/python-list
