[issue24138] Speed up range() by caching and modifying long objects

Guido van Rossum added the comment: (Never mind, that should have gone to https://bugs.python.org/issue24165, which is the integer freelist -- conclusion there in 2015 was also that it didn't do much.) -- ___ Python tracker

[issue24138] Speed up range() by caching and modifying long objects

Guido van Rossum added the comment: Should we try the free list for integers again? -- nosy: +gvanrossum ___ Python tracker ___

[issue24138] Speed up range() by caching and modifying long objects

Larry Hastings added the comment: I'd rather have the general-purpose freelist for ints too. How about we close this issue now, and assuming the freelist for ints goes in we can abandon this approach entirely. -- resolution: - rejected stage: patch review - resolved status: open -

[issue24138] Speed up range() by caching and modifying long objects

Serhiy Storchaka added the comment: According to my and Larry's measurements [1] the distribution of created int's by size during running Python tests is: On 32-bit Linux: int 42828741 13.40% 0 425353 0.99% 0.99%

[issue24138] Speed up range() by caching and modifying long objects

Antoine Pitrou added the comment: I'd rather stick to the simple freelist approach. People interested in (allegedly) more ambitious designs can open new issues, together with patches to evaluate their efficiency. -- ___ Python tracker

[issue24138] Speed up range() by caching and modifying long objects

Marc-Andre Lemburg added the comment: I like the idea of adding a free list of longs in Python 3, but I think we should extend this somewhat to cover more ground, e.g. by pre-allocating a block of 1 digit long objects, like we did for Python 2 ints, and perhaps allocate up to 4k (= 1 memory

[issue24138] Speed up range() by caching and modifying long objects

Serhiy Storchaka added the comment: [1] http://comments.gmane.org/gmane.comp.python.devel/153078 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___

[issue24138] Speed up range() by caching and modifying long objects

Marc-Andre Lemburg added the comment: On 11.05.2015 11:42, Serhiy Storchaka wrote: Pre-allocating a block has a disadvantage. It is hard to free allocated block. The program can create a lot of integers, then drop most of them, and request the memory for other needs, but blocks once

[issue24138] Speed up range() by caching and modifying long objects

Serhiy Storchaka added the comment: Well, 1-4k RAM can be consumed just after the start up (it's only 100-300 integers) and never freed. What next? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138

[issue24138] Speed up range() by caching and modifying long objects

Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list

[issue24138] Speed up range() by caching and modifying long objects

Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file39308/long_free_list.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___

[issue24138] Speed up range() by caching and modifying long objects

Larry Hastings added the comment: 10**3 doesn't show off this hack as much as other numbers would; the hack only operates from 257 to the max in that will fit in a single long digit (32767 on 32-bit, 2**30 on 64-bit). Anyway, freelist for one-digit longs seems nearly as good, and it's a lot

[issue24138] Speed up range() by caching and modifying long objects

Serhiy Storchaka added the comment: This regression was just discussed in issue24076. General suggestion about free list for small ints was proposed. It could speed up other integer computations, but comprehensive benchmarking results are needed. See also similar issue23507 for tuples.

[issue24138] Speed up range() by caching and modifying long objects

Mark Lawrence added the comment: How does this apply where people like me scarcely if ever use range, it's standard for loops? There are plenty of recipes using itertools that show that you don't need range, is this really needed? No axe to grind, just curious. -- nosy: +BreamoreBoy

[issue24138] Speed up range() by caching and modifying long objects

New submission from Larry Hastings: This probably shouldn't be checked in. But it was an interesting experiment, and I did get it to work. My brother forwarded me this question from Stack Overflow:

[issue24138] Speed up range() by caching and modifying long objects

Stefan Behnel added the comment: See issue 24076. -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___ Python-bugs-list

[issue24138] Speed up range() by caching and modifying long objects

Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24138 ___ ___

[issue24138] Speed up range() by caching and modifying long objects

Serhiy Storchaka added the comment: Here is a patch that adds a free list for 1-digit long objects. $ ./python -m timeit -s r = range(10**3) -- for i in r: pass Unpatched: 1 loops, best of 3: 54.4 usec per loop With free list: 1 loops, best of 3: 38 usec per loop With hacked range: