[Python-Dev] Activating pymalloc

[Tim Peters]

[martin@v.loewis.de]
> I also wonder whether it might be sensible to space the size classes
> 16 bytes apart, thus reducing the number of classes to 16.

I don't think so.  What's the upside?  Reducing the size of usedpools?  If
so, I expect the fixed static memory savings would be swamped by the
increase in wasted pad bytes:  for a request of n bytes, the amount acually
allocated would go up from ceiling(n/8)*8 to ceiling(n/16)*16.  For example,
for a "small dict" of 136 bytes, we'd actually allocate 144 instead of 136
bytes, so after allocating 16 dicts we would have wasted an additional 8*16
= 128 bytes, which is already as much memory as we saved in usedpools (16
classes * 2 pointers/class * 4 bytes/pointer = 128 bytes).

When obmalloc.c was first written, there was a much stronger case to be made
that Python object allocation picked on a fixed, small and *known* set of
object sizes.  We've made many more kinds of internal objects since then,
though, and the __slots__ mechanism allows for instances of user-defined
classes to have widely varying sizes too (previously all instances had the
same size).

All of this stuff pushes pymalloc toward being more of a general "small
block allocator" than a Python-specific allocator, and small block
allocators want as little padding as possible.  Indeed, if we could think of
a clean way around the x-platform alignment headaches, I'd be keener to
space the classes by 4 bytes!  The size of usedpools is trivial compared to
the dynamic memory that would save.