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
Performance regression for making bound methods #83298
Comments
$ python3.9 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a = A()' 'a.m; a.m; a.m; a.m; a.m'
1000000 loops, best of 11: 230 nsec per loop
$ python3.8 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a = A()' 'a.m; a.m; a.m; a.m; a.m'
2000000 loops, best of 11: 149 nsec per loop
$ python3.7 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a = A()' 'a.m; a.m; a.m; a.m; a.m'
2000000 loops, best of 11: 159 nsec per loop
$ python3.6 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a = A()' 'a.m; a.m; a.m; a.m; a.m'
10000000 loops, best of 11: 0.159 usec per loop Timings made using the recent released python.org macOS 64-bit builds. |
Probably bpo-37340 |
Is this regression is large enough to revive the free_list for bound methods? |
This performance regression in still present in 3.9.0a6 Results from Tools/scripts/var_access_benchmark.py:
read_boundmethod 27.7 ns 47.1 ns
Yes! |
Extract of Tools/scripts/var_access_benchmark.py: def read_boundmethod(trials=trials, a=A()):
for t in trials:
a.m; a.m; a.m; a.m; a.m
a.m; a.m; a.m; a.m; a.m
a.m; a.m; a.m; a.m; a.m
a.m; a.m; a.m; a.m; a.m
a.m; a.m; a.m; a.m; a.m Which kind of code pattern is impacted by this performance regression, apart this micro-benchmark? Do you notice a significant slowdown in pyperformance? When pyperformance was run before the change was merged, there was no significant difference: In bpo-37340, you wrote that sorted(data, key=str.upper) is 70% slower. Would you mind to provide the benchmark? |
I compared sorted(data, key=str.upper) performance between before the removal of the free list (parent of commit 3e54b57) and the current master branch, I get: Mean +- std dev: [master] 167 us +- 4 us -> [cache] 179 us +- 7 us: 1.07x slower (+7%) I cannot reproduce the "70% slowdown". Raymond: How did you compile Python? What is your OS? How did you run your benchmark? --- It's a quick & dirty benchmark run. I didn't use LTO+PGO and I didn't isolate my CPU. Maybe the difference of 12 ns is just caused by the noise of my coarse benchmark procedure. I used commands: # master # before removal of the free list That's a Fedora 31 using GCC -O3 (GCC 9.3.1). -- The commit before the removal of the free list is: commit 76b6451 (HEAD) Well, maybe I did a mistake. |
By the way, in sorted(data, key=str.upper): str.upper is an unbound method, no? $ ./python
Python 3.9.0a6+ (heads/master:d9a43e20fa, Apr 28 2020, 23:50:37)
>>> type(str.upper)
<class 'method_descriptor'> |
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: