Garbage collection

[Cameron Laird]

True, but why does Python hang on to the memory at all? As I understand it,
it's keeping a big lump of memory on the int free list in order to make
future allocations of large numbers of integers faster. If that memory is
about to be paged out, then surely future allocations of integers will be
*slower*, as the system will have to:

It may not just be that free list -- which on a machine with lots of
RAM may never be paged out anyway [mine (XP) currently shows: physical
memory total/available/system: 2095196/1355296/156900K, commit charge
total/limit/peak: 514940/3509272/697996K (limit includes page/swap file
of 1.5GB)] -- it could easily just be that the OS or runtime just
doesn't return memory to the OS until a process/executable image exits.

.
.
.
.... and there *are* (or at least have been) situations where
it was profitable for an application which knew it had finished
its memory-intensive work to branch to a new instance of itself
in a smaller memory space. That's the only, and necessarily
"tricky", answer to the question about how to make sure all that
free stuff gets back to the OS.

 

[Alex Martelli]

real programs. I can't help thinking that there are some situations where
you need a lot of memory for a short time though, and it would be nice to
be able to use it briefly and then hand most of it back. Still, I see the
practical difficulties with doing this.

What I do in those cases:
a. fork
b. do the memory-hogging work in the child process
c. meanwhile the parent just waits
d. the child sends back to the parent the small results
e. the child terminates
f. the parent proceeds merrily

I learned this architectural-pattern a long, long time ago, around the
time when fork first got implemented via copy-on-write pages...


Alex

 

[Steve Holden]

What I do in those cases:
a. fork
b. do the memory-hogging work in the child process
c. meanwhile the parent just waits
d. the child sends back to the parent the small results
e. the child terminates
f. the parent proceeds merrily

I learned this architectural-pattern a long, long time ago, around the
time when fork first got implemented via copy-on-write pages...

Yup, it's easier to be pragmatic and find the real solution to your
problem than it is to try and mould reality to your idea of what the
solution should be ...

regards
Steve

 

[Alex Martelli]

Yup, it's easier to be pragmatic and find the real solution to your
problem than it is to try and mould reality to your idea of what the
solution should be ...

"That's why all progress is due to the unreasonable man", hm?-)


Alex