classification
Title: Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
Type: resource usage Stage: resolved
Components: Interpreter Core Versions: Python 3.2
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, lemburg, pitrou, terry.reedy
Priority: normal Keywords:

Created on 2009-06-06 00:04 by terry.reedy, last changed 2011-10-24 01:23 by pitrou. This issue is now closed.

Messages (13)
msg88981 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-06-06 00:04
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.
msg88982 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-06-06 00:11
Marc-Andre Lemburg's message is from #1943
msg89002 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-06-06 13:30
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
msg89070 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2009-06-08 08:05
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.
msg89098 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-06-08 19:02
If you write a patch, you are free to include the additional change.
msg110897 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-20 13:51
Terry, are you still interested in this?
msg110927 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-07-20 17:26
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.
msg110951 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-07-20 19:04
You forgot "2) show impact on a couple of benchmarks of his choice", which is arguably the most important.
msg110977 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-07-20 22:14
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?
msg110978 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-07-20 22:30
> 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).
msg111075 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2010-07-21 15:24
I'm interested in getting this into 3.2. Thanks for bringing
the issue back on my radar.
msg121023 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-11-12 06:06
Two weeks left for 3.2 ;-)
msg146275 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-10-24 01:23
Closing as outdated. There are no freelists anymore in the unicode implementation.
History
Date User Action Args
2011-10-24 01:23:28pitrousetstatus: open -> closed
resolution: out of date
messages: + msg146275

stage: resolved
2010-11-12 06:06:23terry.reedysetmessages: + msg121023
2010-07-21 15:24:01lemburgsetmessages: + msg111075
2010-07-20 22:30:01pitrousetmessages: + msg110978
2010-07-20 22:14:25terry.reedysetmessages: + msg110977
2010-07-20 19:04:44pitrousetmessages: + msg110951
versions: - Python 3.1
2010-07-20 17:26:26terry.reedysetmessages: + msg110927
2010-07-20 13:51:00BreamoreBoysetnosy: + BreamoreBoy

messages: + msg110897
versions: + Python 3.2
2009-06-08 19:02:37terry.reedysetmessages: + msg89098
2009-06-08 08:05:17lemburgsetnosy: + lemburg
messages: + msg89070
2009-06-06 13:30:29pitrousetnosy: + pitrou
messages: + msg89002
2009-06-06 00:11:48terry.reedysetmessages: + msg88982
2009-06-06 00:04:12terry.reedycreate