Repository navigation
GH-93657: More LOAD_ATTR specializations - #93892
Fidget-Spinner wants to merge 8 commits into
Conversation
markshannon
left a comment
There was a problem hiding this comment.
Specializing property accesses is clearly worthwhile.
I'm not so sure about mutable descriptors. Do they represent a large enough fraction of attributes, and is the specialized form that much faster?
| NOTRACE_DISPATCH(); | ||
| } | ||
|
|
||
| TARGET(LOAD_ATTR_CLASS_MUTABLE_DESCRIPTOR) { |
There was a problem hiding this comment.
Is this common enough to justify its own specialization, especially as we need to do much of the work of general lookup?
There was a problem hiding this comment.
According to the stats on the faster-cpython repo, this represents 5.7% of the remaining failures. In contrast, properties are 13.8%. Class method objects are quite close, at 6.2%.
Here's a microbenchmark, with no PGO nor LTO, but it's a Windows release build (similar to -O3).
python -m timeit -s "
from enum import Enum
class Colours(Enum):
RED = 1
" "Colours.RED"
# on MAIN:
2000000 loops, best of 5: 121 nsec per loop
2000000 loops, best of 5: 120 nsec per loop
2000000 loops, best of 5: 120 nsec per loop
# on this PR:
5000000 loops, best of 5: 77.2 nsec per loop
5000000 loops, best of 5: 73.5 nsec per loop
5000000 loops, best of 5: 72.1 nsec per loop
With PGO and LTO, I expect the difference to be less dramatic. But I still expect this form to be ~=15% faster than the base version.
There was a problem hiding this comment.
Do you have a non-enum example?
enums members should be simple class attributes.
#93910
There was a problem hiding this comment.
I don't. This opcode was specifically designed with enum in mind.
|
I'm quite surprised that the property specialisation's speedup is less than 2x: Maybe your work in #93897 shall fix that. |
|
Given that #93910 is likely to be messing up our stats, maybe put this hold for a while? |
Specializes for
@property()with Python functions