From msg88801
'''
for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and
motivated here:

msg64215

That's a simple non-disruptive change which makes a lot of sense
due to the advances in CPU designs in the last 9 years. I determined
the original value of 9 using benchmarks and similar statistics in
1999/2000.

It's probably also a good time to remove the warning, now that the
implementation has proven itself for so many years...

/* Limit for the Unicode object free list stay alive optimization.

   The implementation will keep allocated Unicode memory intact for
   all objects on the free list having a size less than this
   limit. This reduces malloc() overhead for small Unicode objects.

   At worst this will result in PyUnicode_MAXFREELIST *
   (sizeof(PyUnicodeObject) + KEEPALIVE_SIZE_LIMIT +
   malloc()-overhead) bytes of unused garbage.

   Setting the limit to 0 effectively turns the feature off.

   Note: This is an experimental feature ! If you get core dumps when
   using Unicode objects, turn this feature off.

*/

#define KEEPALIVE_SIZE_LIMIT       9
'''
If this is as non-controversial as it seems, perhaps someone could
change 9 to 32 and remove "Note: This is an experimental feature..." in
time for rc2.

Marc-Andre Lemburg's message is from #1943

I'm not sure it is "as non-controversial as it seems".
Someone should 1) do the math 2) show impact on a couple of benchmarks
of his choice

I think we should also consider raising the free list limit
of currently 1024 objects.

The keep-alive optimization currently uses at most 1024 * 9 * 2
= 18432 bytes (+ pymalloc overhead) on a UCS2 build of Python in
the worst case.

With a limit of 32 you get 65536 bytes.

Given that Unicode objects are one of the most used object in
Python 3k and looking at todays CPU cache sizes, it would
probably be fair to allocate up to 256kB for such an
optimization, e.g. by allowing up to 4096 objects to reside
in the free list.

If you write a patch, you are free to include the additional change.

Terry, are you still interested in this?

That question should better be directed at Marc-Andre. I merely extracted this sub-issue from one of his posts in the very contentious discussion of #1943, lest it get lost.

Antoine asked for a calculation. Marc-Andre gave one, but I do not know if that is what Antoine wanted. The referenced msg64215 gives 3 string length profiles that suggest that an increase to at least 16 might be useful.

You forgot "2) show impact on a couple of benchmarks of his choice", which is arguably the most important.

I did not forget. I omitted because there were no benchmarks to mention. I admit that silence is sometimes difficult to interpret and that I should have said so. Do you see that incrementing the limit could have negative effects that need to be justified? Just simply the extra space ? or something else?

> I did not forget. I omitted because there were no benchmarks to
> mention. I admit that silence is sometimes difficult to interpret and
> that I should have said so. Do you see that incrementing the limit
> could have negative effects that need to be justified? Just simply the
> extra space ? or something else?

It can always have negative effects in the form of decreased cache
efficiency, or more fragmentation in the memory allocator.
Otherwise we could similarly bump up the size of all freelists in the
interpreter (there are several of them).

I'm interested in getting this into 3.2. Thanks for bringing
the issue back on my radar.

Two weeks left for 3.2 ;-)

Closing as outdated. There are no freelists anymore in the unicode implementation.