[issue2013] Long object free list optimization

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11144/py3k_longfreelist2_gps04.patch ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2013] Long object free list optimization

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: attached is an updated patch that also works in debug mode. to do this i had to exclude all zero length (value = 0) PyLongObjects from the free list. i'm still not sure why, they all have the same underlying allocation size. simplifying i

[issue2013] Long object free list optimization

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: preventing this right now is that when i apply this to py3k today, it fails miserably in a debug build. first, my patch has an invalid assert(size > 0) in it in _PyLong_New as 0 size is used when the value is 0. get rid of that line. then

[issue2013] Long object free list optimization

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Gregory, your patch probably deserves checking in, it doesn't seem to me there is any concern preventing you to do that. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2013] Long object free list optimization

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: The problem with choosing a sensible freelist size is that we don't have any reference workloads. However, I just tested with 1 and it doesn't seem to slow anything down anyway. It doesn't make our microbenchmarks I thought the patch to c

[issue2013] Long object free list optimization

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: And the benchmarks of gps02... see the attached file. At the end I had it run pybench rather than these microbenchmarks that obviously show the speedup, the -gps02 patch ran 1.3% faster best case a 0.5% faster on average (32-bit; my mac's t

[issue2013] Long object free list optimization

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Looking at how much memory was actually used by PyLongObjects the way our code allocates them... we can use this freelist for 2 digit PyLongs on 32-bit systems and for 4 digit PyLongs on 64-bit systems. Doing this speeds things up even more

[issue2013] Long object free list optimization

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I'm attaching a slightly improved version of the longfreelist2 patch. It moves the important test to be first and removes the unneeded ? : conditional. Here are some more benchmarks: --- i

[issue2013] Long object free list optimization

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Here are some updated timings against the current py3k branch: $ ./python -m timeit "sum(range(1))" Without patch: 1000 loops, best of 3: 675 usec per loop With patch: 1000 loops, best of 3: 462 usec per loop $ ./python -m timeit -s "n=

[issue2013] Long object free list optimization

Christian Heimes added the comment: Antoine Pitrou wrote: > Christian, maybe you did your measurements with the DEBUG flag turned > on? That would explain the discrepancy. > > Also, I'm not sure the patch is useful for 2.x since long objects with > size -1 or 1 should be represented as ints inst

[issue2013] Long object free list optimization

Antoine Pitrou added the comment: Christian, maybe you did your measurements with the DEBUG flag turned on? That would explain the discrepancy. Also, I'm not sure the patch is useful for 2.x since long objects with size -1 or 1 should be represented as ints instead :-) _

[issue2013] Long object free list optimization

Antoine Pitrou added the comment: I don't get the same impressive speedup as you do, although it's still significant. $ ./python -m timeit "for i in range(100): list(range(1000))" Without patch: 100 loops, best of 3: 5.05 msec per loop With patch: 100 loops, best of 3: 3.57 msec per loop Also,

[issue2013] Long object free list optimization

Christian Heimes added the comment: The updated patch limits the free list. -- type: -> rfe Added file: http://bugs.python.org/file9361/py3k_longfreelist.patch __ Tracker <[EMAIL PROTECTED]>

[issue2013] Long object free list optimization

New submission from Christian Heimes: The patch adds a free list of long objects with size 1 or -1. It has quite a tremendous effect on code like list(range(1000)). $ ./python -m timeit "for i in range(100): list(range(1000))" Without patch: 10 loops, best of 3: 79 msec per loop With patch: 10