New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32? #50465
Comments
From msg88801 That's a simple non-disruptive change which makes a lot of sense It's probably also a good time to remove the warning, now that the /* Limit for the Unicode object free list stay alive optimization. The implementation will keep allocated Unicode memory intact for At worst this will result in PyUnicode_MAXFREELIST * Setting the limit to 0 effectively turns the feature off. Note: This is an experimental feature ! If you get core dumps when */ #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 bpo-1943 |
I'm not sure it is "as non-controversial as it seems". |
I think we should also consider raising the free list limit The keep-alive optimization currently uses at most 1024 * 9 * 2 With a limit of 32 you get 65536 bytes. Given that Unicode objects are one of the most used object in |
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 bpo-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? |
It can always have negative effects in the form of decreased cache |
I'm interested in getting this into 3.2. Thanks for bringing |
Two weeks left for 3.2 ;-) |
Closing as outdated. There are no freelists anymore in the unicode implementation. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: