[Eric Huss] > Is there a plan to switch the basic objects (int, float, method, etc.) to > use pymalloc instead of the block allocation technique they currently > use? No. pymalloc is slower than a simple dedicated free list. > The reason I ask is because the free_list in these objects is unbounded. Also immortal (once memory has been allocated for an int (float, etc), it can never go away, or be used for anything else, for the life of the process). > It becomes a problem in a server environment if activity spikes cause > different types of objects to start eating memory and never give it up. Yup. > The only problem I see with using pymalloc is that the objects won't be > stored in memory in such a compact way. The difference can be large, because pymalloc aligns to 8-byte boundaries. So, e.g., on most boxes today a Python int object consumes 12 bytes, but would consume 16 if allocated with pymalloc. That's a 33% boost, and that can be significant for apps hanging on to lots of ints. OTOH, on most boxes there would be no real size difference for float objects. > I would imagine there would be no performance difference. Sorry, there is -- and it's in the wrong direction <wink>. > Of course some optimizations (such as small_ints) would stay. > > I would be willing to submit a patch with the change if there is > interest. I think you'd have better luck with a patch that bounded the sizes of these free lists. That's not hard to do; e.g., look at the simple bounded free list in frameobject.c. I wouldn't like a small limit on ints or floats, but letting any subsystem suck up unbounded resource forever does cause problems.
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