[issue45976] Random._randbelow() loses time by caching an attribute lookup

Raymond Hettinger added the comment: I'm thinking that we care more about the unhappy cases (the extreme values) than we care about a mild and implementation dependent improvement to the average case. -- resolution: later -> rejected ___ Python tr

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Andrew Lin added the comment: E[calls] reduces down to 2**k / n. I only just realized from working that out that it therefore doesn't quite vary linearly over [2**k, 2**(k+1)), although by what weight one wants to average I couldn't say. Personally if the change adversely impacts performanc

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Raymond Hettinger added the comment: Notes = Without Boundmethod --- LOAD FAST self LOAD METHOD getrandbits LOAD FAST k CALL_METHOD 1 Form Boundmethod LOAD FAST self LOAD ATTR getrandbits STORE FAST getrandbits Call Boundmethod --

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Change by Andrew Lin : Added file: https://bugs.python.org/file50473/randbelow_timing.py ___ Python tracker ___ ___ Python-bugs-list mailing

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Andrew Lin added the comment: I finally cleaned up my benchmark script, which feels like a big hack. I should really learn to use pyperf or something. Inspired by your comment about 3.8 on the Mac I tried my Ubuntu installation's stock 3.8. I get a small degradation (~0.5%) for powers of t

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Raymond Hettinger added the comment: On the current 3.11, I do get a speedup below a power of two, but a slight degradation (as expected) at power of two. python3.11 -m timeit -s 'from random import randrange' 'randrange(65535)' python3.11 -m timeit -s 'from random import randrange' 'randrang

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Raymond Hettinger added the comment: I just did a few timings using the stock python.org Mac builds. Only Python 3.10 gave the expected speed-up. Python 3.8 and Python 3.9 got slower. Python 3.11 was slightly slower. I think we should pass on this proposed change. The current code is saf

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Andrew Lin added the comment: Timings are unaffected by updating to non-walrus, so I'll do so in the PR. Using _randbelow_without_getrandbits() I get 5% improvement to sample([None] * 2047, 50); 6% to shuffle([None] * 2000); and approximately 6% to randrange() for any number significantly le

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Raymond Hettinger added the comment: * If you post a timing script, it will make it easier for me to verify this across versions and across machine and for various input sizes. * If you have time, do run some benchmarks for _randbelow_without_getrandbits() * Try your change with and without

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Raymond Hettinger added the comment: Thanks for the suggestion. I'll try this out on various builds and machines to see how it works out. The speed of locals is consistently fast, but the speed of method calls has varied over the last few versions of Python (generally getting faster). Whe

[issue45976] Random._randbelow() loses time by caching an attribute lookup

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 1.0 -> 2.0 pull_requests: +28136 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29911 ___ Python tracker _

[issue45976] Random._randbelow() loses time by caching an attribute lookup

New submission from Andrew Lin : This PR obtains a performance improvement in the random module by removing a cached attribute lookup in Random._randbelow_with_getrandbits() that costs time on average. In the best cases (on my machine) I get 10% improvement for randrange(), 7% for shuffle(),