I've spent some time recently in reviving the pymalloc project, and now
that Python has GC and is fairly clean w.r.t. its allocators, I think
I'm going to suggest the inclusion of pymalloc as an object allocator
(i.e. obmalloc).
Three main reasons motivate this suggestion:
1. obmalloc keeps under control the memory allocated for most objects;
2. it compensates for the space overhead induced by GC;
3. it gives worthy speedups.
To give it a try, see: http://starship.beopen.com/crew/vlad/pymalloc/
It's basically a VMM aware, generalized free list implementation which
handles dynamically small mem blocks (small = under 64 bytes for combos
with 4-byte pointers). This accounts for > 95% of all object structs
allocated by Python.
Thread safety is disabled (just like the other object-specific allocators).
There's no profiling for the moment. I'm going to rewrite entirely the
stats code, but still, give it a try in the meantime.
I have only rough numbers, but my preliminary tests indicate that
for memory consuming scripts, GC increases the peak mem usage by more
than 5% (5 to 15% and up) compared to no-GC, and obmalloc decreases that
to something in between GC and no-GC. Sometimes also below no-GC. This
is due to the fact that obmalloc does not introduce per block overhead
for every allocation, as standard libc mallocs do.
I consistently get speedups of 3%-20% for long-enough running scripts
(on Linux, Solaris and AIX).
Regarding space, for low-mem consuming scripts, obmalloc increases
the mem usage (reservation) as it preallocates & suballocates 256k
blocks, but I'm not interested in low-mem consuming scripts. Things
start to be interesting for higher mem consumptions.
Just an example with regrtest.py on my setup: The (peak) requested
memory is about 4 MB. GC adds 150 KB more compared to no-GC.
With GC and with obmalloc, I sometimes get 100k less compared to
no-GC. This is optimistic, but I won't argue more about it, because
these are all virtual memory numbers.
All this needs to be pursued, probably PEP'ed, but I think I can
already emit my opinion about a compromise:
If obmalloc.c gets in 2.0, I am okay to leave GC enabled for 2.0 final.
Probably obmalloc needs to go in pair with GC. And Neil & al. can make
use of it as a basis for further enhancements of the GC code (note that
most of the object mem is now under Python's control).
That said, it would be nice if you could test this code on your combos
and report some results and impressions back here.
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
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