In article <[EMAIL PROTECTED]>,
Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
>On Wed, 21 Mar 2007 15:32:17 +0000, Tom Wright <[EMAIL PROTECTED]>
>declaimed the following in comp.lang.python:
>
>>
>> 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.
--
http://mail.python.org/mailman/listinfo/python-list
