Antoine Pitrou pit...@free.fr added the comment:
Closing as outdated. There are no freelists anymore in the unicode
implementation.
--
resolution: - out of date
stage: - committed/rejected
status: open - closed
___
Python tracker
Terry J. Reedy tjre...@udel.edu added the comment:
Two weeks left for 3.2 ;-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6216
___
___
Marc-Andre Lemburg m...@egenix.com added the comment:
I'm interested in getting this into 3.2. Thanks for bringing
the issue back on my radar.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6216
Mark Lawrence breamore...@yahoo.co.uk added the comment:
Terry, are you still interested in this?
--
nosy: +BreamoreBoy
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6216
Terry J. Reedy tjre...@udel.edu added the comment:
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
Antoine Pitrou pit...@free.fr added the comment:
You forgot 2) show impact on a couple of benchmarks of his choice, which is
arguably the most important.
--
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
Terry J. Reedy tjre...@udel.edu added the comment:
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
Antoine Pitrou pit...@free.fr added the comment:
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
Marc-Andre Lemburg m...@egenix.com added the comment:
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
Terry J. Reedy tjre...@udel.edu added the comment:
If you write a patch, you are free to include the additional change.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6216
___
Antoine Pitrou pit...@free.fr added the comment:
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
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
New submission from Terry J. Reedy tjre...@udel.edu:
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
Terry J. Reedy tjre...@udel.edu added the comment:
Marc-Andre Lemburg's message is from #1943
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6216
___
13 matches
Mail list logo