This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients ajaksu2, amaury.forgeotdarc, collinwinter, eric.smith, ezio.melotti, gvanrossum, jafo, jimjjewett, lemburg, orivej, pitrou, rhettinger
Date 2009-06-04.12:13:31
SpamBayes Score 2.1485813e-10
Marked as misclassified No
Message-id <4A27BA65.8000706@egenix.com>
In-reply-to <1244114906.4913.1.camel@localhost>
Content
Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> Since pymalloc is being used to manage such objects, there's
>> a lot of room for improvements, since the allocation scheme
>> is under out control. E.g. we could have pymalloc allocate
>> larger pools for PyUnicodeObjects.
> 
> I'm not sure what "larger pools for PyUnicodeObjects" means. pymalloc
> doesn't have separate pools per object type, only per object size.

I meant larger pools for objects of sizeof(PyUnicodeObject) bytes.
The same could be done for other often used PyObjects (and only for
those).

pymalloc is a lot faster than the OS malloc() and was designed for
Python object memory management, ie. for small blocks...

"""
/* A fast, special-purpose memory allocator for small blocks, to be used
   on top of a general-purpose malloc -- heavily based on previous art. */

/* Vladimir Marangozov -- August 2000 */
"""

> OTOH, we could grow the size limit under which pymalloc is used,
> especially on 64-bit systems.

The limit is 256 bytes. Increasing it doesn't make much sense,
since the pools are 4k each and managed in arenas of
256kb.

Anything larger than 256 bytes goes straight to the OS malloc().
History
Date User Action Args
2009-06-04 12:13:36lemburgsetrecipients: + lemburg, gvanrossum, collinwinter, rhettinger, jafo, jimjjewett, amaury.forgeotdarc, pitrou, eric.smith, ajaksu2, orivej, ezio.melotti
2009-06-04 12:13:33lemburglinkissue1943 messages
2009-06-04 12:13:31lemburgcreate