By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,975 Members | 1,216 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,975 IT Pros & Developers. It's quick & easy.

python 3.0 memory leaking?

P: n/a
the edgewall trac release 0.11 is blocked now since more than one
month for a memory leak nobody is able to find, see
http://groups.google.com/group/trac-...16e519da54f16b
..

does python-3.0 improve something to avoid writing memory leaking
applications?

rupert.
Feb 10 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Hi Rupert,

-On [20080210 20:16], rupert.thurner (ru************@gmail.com) wrote:
>the edgewall trac release 0.11 is blocked now since more than one
month for a memory leak nobody is able to find, see
http://groups.google.com/group/trac-...16e519da54f16b
.
You are slightly mistaken that nobody is able to find anything. There is
currently a lot underway to fix this. The problem was not just one area, but
problems on a number of areas. Given the fact nobody uses a large enough
site with a 0.11 trunk installation these sort of things will start to show
during beta test, as it did. This is still beta period and I personally
would rather release a month later (even despite the already long release
time) than give our users a solution that eats away at their resources like
crazy. I am sure people will appreciate the latter more in the end. Already
the current fixes in trunk for Trac and Genshi stabilized a few large beta
deployment sites in terms of resource eating.
>does python-3.0 improve something to avoid writing memory leaking
applications?
There are efforts underway to optimize the memory usage for 2.6 on a lot of
levels more than 2.5 already did. Check Python-dev of the last 2-3 weeks.
However, this is not interesting in the short term, since 2.4 and 2.5 (and
later on 2.6) will be versions that will be used for the coming 1-2 years
for sure. Avoidance is very difficult, especially given Python's dynamic
nature. But I'll let more knowledgeable minds talk about that.

For me, a relative newbie to Python, the entire memory allocation issue is
not transparent at all and information about it is scattered across the net.
One of the things I hope to contribute to in the coming year is to make sure
the entire area of Python memory use and proper coding is better understood.

--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org/ asmodai
イェルーン ラウフ*ック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
What is to be, will be. And what isn't to be sometimes happens...
Feb 10 '08 #2

P: n/a
rupert.thurner wrote:
does python-3.0 improve something to avoid writing memory leaking
applications?
No, it doesn't. Python 3.0 and maybe 2.6 are going to have some small
improvements but the improvements aren't related to memory leaking. I'm
working on the matter for a while now. I've limited some free lists and
I've a patch that gives allocated memory back to the OS earlier.

Have you followed my advice and checked all places that deal with
frames, tracebacks, exception objects and __del__ methods?

Christian

Feb 10 '08 #3

P: n/a
On Feb 10, 9:08*pm, Christian Heimes <li...@cheimes.dewrote:
rupert.thurner wrote:
does python-3.0 improve something to avoid writing memory leaking
applications?

No, it doesn't. Python 3.0 and maybe 2.6 are going to have some small
improvements but the improvements aren't related to memory leaking. I'm
working on the matter for a while now. I've limited some free lists and
I've a patch that gives allocated memory back to the OS earlier.

Have you followed my advice and checked all places that deal with
frames, tracebacks, exception objects and __del__ methods?

Christian
many thanks christian! do you have any code examples how to handle
frames, tracebacks, exception objects and __del__ correctly?

btw, i put your hints on http://wiki.python.org/moin/FreeMemory.

rupert.
Feb 10 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.