homepage

floatobject.c has its own block allocator. This appears to be ancient, from before the time when obmalloc.c was invented.
This patch removes this allocator and puts an upper limit on the freelist of floats. The purpose of this is to reduce memory fragmentation, since blocks used for floats cannot be used for anything else in python. These blocks tend to stay around for a long time, it is sufficient for one float from each of the 1k blocks to be alive to keep that block present in memory forever.
It is the presence of the fast freelist that is the performance enhancer here, not the fast block allocator.

One thing: PyFloat_ClearFreeList() is supposed to return the number of objects previously in the freelist, not zero.
Also, perhaps 10 is a bit on the small side for the number of objects kept on the freelist. 100 instead? Or do you think that's too large?

Yes, it is supposed to, but no one is actually looking at that value. It was used in debugging information during PyFloat_Fini() which is no longer relevant if this block information is removed.
Sure, 100 or 10 does not matter, I see 100 being used in some other freelists.
Also, I wasn't able to see any negative benefits of this using pybench.
Here's a thought: I think using the linked list approach using Py_TYPE() is rather neat. Other freelists are mostly implemented using static arrays of pointers. Any thoughts on this? We could unify the approach taken.

> Yes, it is supposed to, but no one is actually looking at that value.
> It was used in debugging information during PyFloat_Fini() which is no
> longer relevant if this block information is removed.
Still, let's honour the API rather than break it.
> Here's a thought: I think using the linked list approach using
> Py_TYPE() is rather neat. Other freelists are mostly implemented
> using static arrays of pointers. Any thoughts on this? We could
> unify the approach taken.
I don't have any preference either way, but I see little point in
unifying the approach, since no common code is shared.

Correction: The number returned was the number of floats in existence, not the size of the freelist. Do you think I should add a counter to support that functionality? I ́d rather change it to be the size of the old freelist, similar to PyTuple_ClearFreeList().

> Do you think I should add a counter to support that functionality? I
> ́d rather change it to be the size of the old freelist, similar to
> PyTuple_ClearFreeList().
It should be the size of the old freelist, indeed.

Here is a new patch, with the suggested changes. The variable names and macros are similarly named as those for other objects such as lists.

> Here is a new patch, with the suggested changes. The variable names
> and macros are similarly named as those for other objects such as
> lists.
Looks good to me.

New changeset 37ebe64d39d2 by Kristján Valur Jónsson in branch 'default':
Issue #14435: Remove special block allocation code from floatobject.c
http://hg.python.org/cpython/rev/37ebe64d39d2 

All done.

New changeset 10fcaf5903e6 by Kristján Valur Jónsson in branch 'default':
Issue #14435: Add Misc/NEWS and Misc/ACKS
http://hg.python.org/cpython/rev/10fcaf5903e6