Guido van Rossum wrote:
If it is truly opt-in (supposedly a configure option?), I'm all for it.
It is very much opt-in.
I recall vaguely though that Jeremy or Tim thought that the patch touches lots of code even when one doesn't opt in. That was a no-no so close before the a2 release. Anybody who actually looked at the code got an opinion on that now?
I suggest looking at the patch. Not at the code, but what it does as a diff:
1) Add a file Objects/obmalloc.c 2) Add stuff to configure.in & config.h to detect the --with-pymalloc argument to ./configure 3) Conditionally #include "obmalloc.h" in Objects/object.c if WITH_PYMALLOC is #defined 4) Conditionally #define the variables in Include/objimpl.h to #define the #defines needed to override the memory imiplementation if WITH_PYMALLOC is #defined
And *that's it*. That's not my definition of "touches a lot of code".
OK, I just looked, and I agree. BTW, for those who want to look, the URL is:
http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470
This is currently assigned to Barry. Barry, can you see if this is truly fit for inclusion? Or am I missing something?
Note that there's a companion patch that adds a memory profiler:
http://sourceforge.net/patch/?func=detailpatch&patch_id=101229&group_id=5470
Should this also be applied? Is there a reason why it shouldn't?
Since both patches must be explicitely enabled by a configure switch I'd suggest to apply both of them -- this will give them much more testing. In the long run, I think that using such an allocator is better than trying maintain free lists for each type seperatly. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/