[Python-Dev] int/float freelists vs pymalloc

[Christian Heimes]

Andrew MacIntyre wrote:
> I seem to recall Tim Peters paying a lot of attention to cache effects
> when he went over the PyMalloc code before the 2.3 release, which would
> contribute to its performance.

Well, I guess we have to ask Uncle Tim on this matter and ask for his
opinion. I've no experience with optimization on the level of CPU cache
lines. But it sounds interesting. Does somebody have an advice for some
articles or a good book?

> I tested the updated patch you added to issue 2039.  With the int
> freelist set to 500 and the float freelist set to 100, its about the same
> as the no-freelist version for my tests, but PyBench shows the simple
> float arithmetic to be about 10% better.
> 
> I'm inclined to set the int LIFO a bit larger than you suggest, simply as
> ints are so commonly used - hence the value of 500 I used.  Floats are
> much less common by comparison.  Even an int LIFO of 500 is only going to
> tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant
> enough that I can't see a need for a compaction routine.
> 
> A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on
> 64bit).

I added some profiling code to lists and dicts. Increasing the free list
size didn't make a difference for lists and dicts. I used 200 instead of
80 for the free list size and the ratio of reuse / allocation increased
minimal.

Every entry in the free list costs 4 bytes for the pointer and 16 bytes
for the int or float object on 32bit including padding on 8byte address
boundaries. For 500 objects that's about 9kb which isn't a big deal
nowadays. But - andere there is always a but - every object may keep a
4kb arena alive.

Unless a program is creating and destroying lots of ints at once a
larger number doesn't make a performance difference. I'd stick to 80,
maybe 120 for ints for now.

> I'd like to think that these changes could be considered fixes for
> performance bugs so that they could be applied for 2.5.2, but I doubt
> that will fly.

Not a chance ;)

Christian