Issue 46564: Near zero-cost super().meth() calls via adaptive superinstructions
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) *  |
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 https://github.com/faster-cpython/ideas/issues/242 and https://github.com/faster-cpython/ideas/discussions/239 for more info. |
|||
| msg412050 - (view) | Author: Kumar Aditya (kumaraditya) *  |
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) * |
Date: 2022-01-29 05:16 | |
@Kumar, my PR already has your changes. |
|||
| msg412052 - (view) | Author: Kumar Aditya (kumaraditya) * |
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) * |
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) * |
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) https://github.com/python/cpython/commit/b9ebde8db7e176e021103745cd012bae700828b5 |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:55 | admin | set | github: 90722 |
| 2022-03-29 17:49:41 | corona10 | set | nosy:
+ corona10 |
| 2022-02-01 13:41:23 | kj | set | messages: + msg412259 |
| 2022-01-29 06:28:26 | kj | set | messages: + msg412055 |
| 2022-01-29 05:21:14 | kumaraditya | set | messages: + msg412052 |
| 2022-01-29 05:16:18 | kj | set | messages: + msg412051 |
| 2022-01-29 04:59:22 | kumaraditya | set | pull_requests: + pull_request29184 |
| 2022-01-29 04:58:38 | kumaraditya | set | nosy:
+ kumaraditya messages: + msg412050 |
| 2022-01-28 16:47:42 | kj | set | keywords:
+ patch stage: patch review pull_requests: + pull_request29172 |
| 2022-01-28 16:36:58 | kj | create | |