[ python-Bugs-1338264 ] Memory keeping

SourceForge.net noreply at sourceforge.net
Mon Oct 31 10:06:05 CET 2005


Bugs item #1338264, was opened at 2005-10-26 15:37
Message generated for change (Comment added) made by sin_avatar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: sin (sin_avatar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory keeping

Initial Comment:
I execute this code on python 2.4.2 (authentic copy from 
console):
Python 2.4.2 (#1, Oct 26 2005, 14:45:33)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more 
information.
>>> a = range(1,10000000)
>>> del a

before i type del - i run top and get (see console output 
below):
16300 sin           2   0   162M   161M poll     0:02 35.76% 
 9.28% python2.4

after del (console below):
16300 sin           2   0   162M   161M poll     0:03  7.18% 
 6.05% python2.4

I tried gc too ... but python didn't free memory. I checked 
this on windows - memory was freed, but interpreter with 
0 defined variables "eat" about 75 Mb!. I think this is bug 
in interpereter core.

some text from dmesg for you:
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 
1992, 1993, 1994
        The Regents of the University of California. All rights 
reserved.
FreeBSD 4.8-RELEASE #0: Thu Apr  3 10:53:38 GMT 
2003
    root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/
GENERIC
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 
686-class CPU)
  Origin = "GenuineIntel"  Id = 0x673  Stepping = 3
  Features=0x387f9ff<FPU,VME,DE,PSE,TSC,MSR,
PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,
PSE36,PN,MMX,FXSR,SSE>
real memory  = 268369920 (262080K bytes)
avail memory = 255901696 (249904K bytes)


----------------------------------------------------------------------

>Comment By: sin (sin_avatar)
Date: 2005-10-31 14:06

Message:
Logged In: YES 
user_id=1368129

One more time.
>>> a = [1 for i in xrange(10000000)]
>>> del a
This code clear - and this not raise "memory keeping"(!)

>>> a = [i for i in xrange(10000000)]
>>> del a
But this code take about 163 Mb on my freeBSD. I can't
udestood why you don't care about this?
P.S. somebody explain me phrase "a) not a bug (integer 
freelists)"


----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-10-31 11:56

Message:
Logged In: YES 
user_id=341410

Suggested close because and/or:
a) not a bug (integer freelists)
b) platform specific malloc/free behavior on the
list->ob_item member (some platforms will drop to 121M
allocated memory after the deletion)
c) OP didn't listen when it was suggested they use xrange()
instead of range()

----------------------------------------------------------------------

Comment By: sin (sin_avatar)
Date: 2005-10-31 11:15

Message:
Logged In: YES 
user_id=1368129

Certainly, i 'am not a C guru, but i uderstood - if interpreter 
keep more than 100Mb, and not keep useful information - it's 
suxx. Fore example if i use my script as a part Zope portal - it 
would be awful. Certainly my script was just example - but if i 
use mult-thread server wrote on python and create list in each 
thread - i would take memory from system and i cannot give it 
back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-10-28 01:38

Message:
Logged In: YES 
user_id=31435

Space for integer objects in particular lives in an immortal 
free list of unbounded size, so it's certain in the current 
implementation that doing range(10000000) will hang on to 
space for 10 million integers forever.  If you don't want that, 
don't do that ;-)  Iterating over xrange(10000000) instead will 
consume very little RAM.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-10-28 01:29

Message:
Logged In: YES 
user_id=341410

>From what I understand, whether or not the Python runtime
"frees" memory (which can be freed) is generally dependant
on platform malloc() and free().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470


More information about the Python-bugs-list mailing list