[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4