Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Wed, 06 Mar 2013 08:18:00 -0500
From: Dave Angel <davea@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Set x to  to None and del x doesn't release memory in python 2.7.1 (HPUX 11.23, ia64)
References: <390f0dc5-5750-4849-9433-a19d90cc8566@googlegroups.com> <87zjyhhret.fsf@nautilus.nautilus> <mailman.2934.1362564689.2939.python-list@python.org> <18272cff-cfb0-4bd3-8f5d-3b4641ba828e@googlegroups.com>
In-Reply-To: <18272cff-cfb0-4bd3-8f5d-3b4641ba828e@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2943.1362575899.2939.python-list@python.org>
Lines: 47
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:40633

On 03/06/2013 05:25 AM, Bryan Devaney wrote:
> On Wednesday, March 6, 2013 10:11:12 AM UTC, Wong Wah Meng-R32813 wrote:
>> Hello there,
>>
>>
>>
>> I am using python 2.7.1 built on HP-11.23 a Itanium 64 bit box.
>>
>>
>>
>> I discovered following behavior whereby the python process doesn't seem to release memory utilized even after a variable is set to None, and "deleted". I use glance tool to monitor the memory utilized by this process. Obviously after the for loop is executed, the memory used by this process has hiked to a few MB. However, after "del" is executed to both I and str variables, the memory of that process still stays at where it was.
>>
>>   <SNIP>
>>
>
> Python uses a 'garbage collector'. When you delete something, all references are removed from the object in memory, the memory itself will not be freed until the next time the garbage collector runs. When that happens, all objects without references in memory are removed and the memory freed.  If you wait a while you should see that memory free itself.
>

Actually, no.  The problem with monitoring memory usage from outside the 
process is that memory "ownership" is hierarchical, and each hierarchy 
deals in bigger chunks.  So when the CPython runtime calls free() on a 
particular piece of memory, the C runtime may or may not actually 
release the memory for use by other processes.  Since the C runtime 
grabs big pieces from the OS, and parcels out little pieces to CPython, 
a particular big piece can only be freed if ALL the little pieces are 
free.  And even then, it may or may not choose to do so.

Completely separate from that are the two mechanisms that CPython uses 
to free its pieces.  It does reference counting, and it does garbage 
collecting. In this case, only the reference counting is relevant, as 
when it's done there's no garbage left to collect.  When an object is no 
longer referenced by anything, its count will be zero, and it will be 
freed by calling the C library function.  GC is only interesting when 
there are cycles in the references, such as when a list contains as one 
of its elements a tuple, which in turn contains the original list. 
Sound silly?  No, it's quite common once complex objects are created 
which reference each other.  The counts don't go to zero, and the 
objects wait for garbage collection.

OP:  There's no need to set to None and also to del the name.  Since 
there's only one None object, keeping another named reference to that 
object has very little cost.



-- 
DaveA