This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Near zero-cost super().meth() calls via adaptive superinstructions
Type: performance Stage: patch review
Components: Interpreter Core Versions: Python 3.11
Status: open Resolution:
Dependencies: Superseder:
Assigned To: kj Nosy List: Mark.Shannon, corona10, kj, kumaraditya
Priority: normal Keywords: patch

Created on 2022-01-28 16:36 by kj, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 30992 open kj, 2022-01-28 16:47
PR 31002 merged kumaraditya, 2022-01-29 04:59
Messages (6)
msg412005 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2022-01-28 16:36
`super().meth()` is expensive. I propose to optimize 3 parts of this:

1. Avoid creating a temporary super() proxy object.
2. Avoid creating a bound method.
3. Avoid method lookup in super MRO using the inline cache.

Credit for 1. and 2. doesn't belong to me. Those were inspired by the excellent work done in issue43563.

I'll do this by combining the adjacent CALL (super) and LOAD_METHOD instructions into CALL_NO_KW_SUPER__LOAD_METHOD. Using the specializer means:

- We don't touch any compiler code.
- This custom instruction isn't revealed to the user
- I can make use of the 5 cache entries shared by both CALL_ADAPTIVE and LOAD_METHOD_ADAPTIVE.

The final 2-argument super(type, obj).meth() form will have almost no overhead over a corresponding self.meth() call in the current implementation.

Please see and for more info.
msg412050 - (view) Author: Kumar Aditya (kumaraditya) * (Python triager) Date: 2022-01-29 04:58
I was reading typeobject.c and noticed that creating a super object currently requires creating a frame object which is created lazily and is slow and it would work with the InterpreterFrame as well so I created a PR for this optimization and now it does not requires creating frame objects.
msg412051 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2022-01-29 05:16
@Kumar, my PR already has your changes.
msg412052 - (view) Author: Kumar Aditya (kumaraditya) * (Python triager) Date: 2022-01-29 05:21
Oh, I didn't see your PR and commented as it was not mentioned in this bpo. Would you like to split the PR or continue with yours, either way is fine?
msg412055 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2022-01-29 06:28
> Oh, I didn't see your PR and commented as it was not mentioned in this bpo.

No problem. In the future please check the "Pull Requests" section on the issue. People don't always say "I created a PR at xxx". Often times we just link the PR into the issue itself.

Keep your PR around in case mine gets rejected, then we can take just the good parts. If mine's accepted, we can close yours.
msg412259 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2022-02-01 13:41
New changeset b9ebde8db7e176e021103745cd012bae700828b5 by Kumar Aditya in branch 'main':
bpo-46564: do not create frame object for super object (GH-31002)
Date User Action Args
2022-04-11 14:59:55adminsetgithub: 90722
2022-03-29 17:49:41corona10setnosy: + corona10
2022-02-01 13:41:23kjsetmessages: + msg412259
2022-01-29 06:28:26kjsetmessages: + msg412055
2022-01-29 05:21:14kumaradityasetmessages: + msg412052
2022-01-29 05:16:18kjsetmessages: + msg412051
2022-01-29 04:59:22kumaradityasetpull_requests: + pull_request29184
2022-01-29 04:58:38kumaradityasetnosy: + kumaraditya
messages: + msg412050
2022-01-28 16:47:42kjsetkeywords: + patch
stage: patch review
pull_requests: + pull_request29172
2022-01-28 16:36:58kjcreate