GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — bpo-45340: Don't create object dictionaries unless actually needed by markshannon · Pull Request #28802 · python/cpython Conversation
|
|
Needs NEWS and some additional documentation. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Some comments about LOAD_METHOD.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| if (*owner_dictptr) { | ||
| SPECIALIZATION_FAIL(LOAD_METHOD, SPEC_FAIL_IS_ATTR); | ||
| goto fail; |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Does this reduce the specialization rates by much?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I didn't check. Overall performance is up a bit, so that's good enough for this PR 🙂
We will need to recheck the specialization rates and kinds of failures for LOAD_ATTR, STORE_ATTR and LOAD_METHOD. From my superficial scan, it appears that the kinds of failures are more clustered, which bodes well.
But changing all that in this PR would just confuse matters.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| assert(self_cls->tp_dictoffset > 0); | ||
| assert(self_cls->tp_inline_values_offset > 0); | ||
| PyDictObject *dict = *(PyDictObject **)(((char *)self) + self_cls->tp_dictoffset); | ||
| DEOPT_IF(dict != NULL, LOAD_METHOD); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Wait is this due to the new scheme that objects shouldn't have dict unless really required?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is. We assume that having no __dict__ is the most common case, so it isn't worth bothering to check for the shared key dict case.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| PyObject *descr = NULL; | ||
| DesciptorClassification kind = 0; | ||
| kind = analyze_descriptor(owner_cls, name, &descr, 0); | ||
| // Store the version right away, in case it's modified halfway through. |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity: is there a reason why we don't need to do this immediately anymore? Are the new dictionary operations atomic/don't call any _PyType_Lookup?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
We used to call _Py_dict_lookup, which could do anything, now we call _PyDictKeys_StringLookup which cannot.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
🤖 New build scheduled with the buildbot fleet by @markshannon for commit 7978220 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
🤖 New build scheduled with the buildbot fleet by @markshannon for commit 8c894f3 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
The buildbot failures are:
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Benchmark of final version: 1% faster |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| if (owner_cls->tp_inline_values_offset) { | ||
| PyObject **owner_dictptr = _PyObject_DictPointer(owner); | ||
| assert(owner_dictptr); | ||
| if (*owner_dictptr) { |
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
@markshannon I'm somewhat confused why anything with a dict pointer is now an attribute, even without looking into said dict. Is there a reason elsewhere (or is this so that we don't need another opcode for the other dict form)?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Anything will a dict pointer will be a miss for LOAD_INSTANCE_VALUE, so I'm assuming it isn't worth optimizing.
Maybe we should attempt to optimize this using LOAD_ATTR_WITH_HINT at this point?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
This code seems to be for LOAD_METHOD_CACHED. I'll try to play around with it and see if the dictionary matters (versus LOAD_ATTR_INSTANCE_VALUE/LOAD_ATTR_WITH_HINT and such.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.