[Python-Dev] RE: Program very slow to finish
M.-A. Lemburg
mal@lemburg.com
Tue, 06 Nov 2001 18:29:39 +0100
Neil Schemenauer wrote:
>
> Tim Peters wrote:
> > Can any Python-Dev'er make time to dig into the advisability of making
> > PyMalloc the default? I only took time for this because I'm out sick today,
> > and was looking for something mindless to occupy my fevered thoughts; alas,
> > it paid off <wink>. I recall there are still thread issues wrt PyMalloc,
> > and there *were* some reports that PyMalloc was slower on some platforms.
>
> The problem is with extension modules. We can make sure code in CVS
> always has the big lock held when calling PyMalloc. We can't be sure
> that extension modules are safe.
>
> The other, more serious problem is that many extension modules allocate
> memory with PyObject_New() and free it with free() or PyMem_DEL()
> instead of PyObject_Del() or PyObject_DEL(). If pymalloc is enabled
> then memory allocated by a PyObject_* function must be freed by a
> PyObject_* funciton.
>
> mxDateTime is the first module I ran into that does this but there are
> many others I'm sure. I think almost all of the C modules I have
> written do it. The code in xxmodule.c used to do it as well.
What is considered the "right" approach for this ? Should Python
objects *always* be deallocated using one of PyObject_Del() and
PyObject_DEL() or is PyMem_DEL() usable as well ?
The reason I'm asking is that the mxDateTime objects I'm
deallocating are actually unreferenced objects on a
free list, so PyObject_Del() will probably bomb on them.
Also, what should be done with failing constructors ? I usually
use PyMem_DEL() to prevent the deallocator from being called but
still free the allocated memory. Is that the correct approach ?
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/