On Dec 27, 2005, at 9:05 AM, Andrea Arcangeli wrote:
I run into a problem recently with a reconnectingclientfactory with
twisted while write some spare time software, that turned out to be
a gc
inefficiency.
In short the protocol memory wasn't released after the reconnect
and the
On Thu, Dec 29, 2005 at 04:22:35AM -0500, Bob Ippolito wrote:
In this particular case, you might be better off just writing some
Twisted code that periodically checks the size of the current process
and does a gc.collect() when necessary. Of course, it requires some
platform specific
On Wed, Dec 28, 2005 at 07:14:32PM -0700, Neil Schemenauer wrote:
[This message has also been posted.]
Martin v. Löwis [EMAIL PROTECTED] wrote:
One challenge is that PyObject_GC_Del doesn't know how large the memory
block is that is being released. So it is difficult to find out how
much
Hello,
I run into a problem recently with a reconnectingclientfactory with
twisted while write some spare time software, that turned out to be a gc
inefficiency.
In short the protocol memory wasn't released after the reconnect and the
protocol had about 50M attached to it. So with frequent
On Tue, Dec 27, 2005, Andrea Arcangeli wrote:
My suggestion to fix this problem in autopilot mode (without requiring
explicit gc.collect()) is to invoke a gc.collect() (or anyway to go
deep down freeing everything possible) at least once every time the
amount of anonymous memory allocated by
Andrea Arcangeli wrote:
To implement this we need two hooks, in the malloc and free that
allocate python objects. Then we have to store the minimum of this
value (i.e. the last minimum of memory allocated by the interpreter).
I would like to underline Aahz' comment: it is unlikely that
On Wed, Dec 28, 2005 at 03:32:29PM +0100, Martin v. Löwis wrote:
you should really consider comming up with a patch yourself. Bonus
points if the code integrates with the current strategies, instead
of replacing them.
As I wrote in the first email, I've no intention to replace anything.
The
On Wed, Dec 28, 2005 at 05:52:06AM -0800, Aahz wrote:
If you feel comfortable with C code, the best way to get this to happen
would be to make the change yourself, then test to find out what effects
I'm more confortable with C code than with python code, that's not the
problem (infact I think
Andrea Arcangeli wrote:
If there's anybody willing to suggest the files to hook into (the
location where the interpreter allocates all anonymous memory) and how
to invoke gc.collect() from C, that would help. thanks!
It all happens in Modules/gcmodule.c:_PyObject_GC_Malloc. There are
Martin v. Löwis [EMAIL PROTECTED] wrote:
One challenge is that PyObject_GC_Del doesn't know how large the memory
block is that is being released. So it is difficult to find out how
much memory is being released in the collection.
Another idea would be to add accounting to the PyMem_*
[Martin v. Löwis]
...
One challenge is that PyObject_GC_Del doesn't know how large the
memory block is that is being released. So it is difficult to find out how
much memory is being released in the collection.
Impossible in some cases is accurate. When pymalloc isn't enabled,
all these
11 matches
Mail list logo
