Repository navigation
Create frame objects lazily when needed #88756
Description
| BPO | 44590 |
|---|---|
| Nosy | @gvanrossum, @ncoghlan, @vstinner, @markshannon, @pablogsal |
| PRs | _PyInterpreterFrame to _Py_framedata #27525 |
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:
assignee = 'https://github.com/markshannon'
closed_at = <Date 2021-07-29.10:31:08.811>
created_at = <Date 2021-07-09.10:53:40.343>
labels = ['interpreter-core', '3.11', 'performance']
title = 'Create frame objects lazily when needed'
updated_at = <Date 2022-02-23.15:14:23.151>
user = 'https://github.com/markshannon'bugs.python.org fields:
activity = <Date 2022-02-23.15:14:23.151>
actor = 'vstinner'
assignee = 'Mark.Shannon'
closed = True
closed_date = <Date 2021-07-29.10:31:08.811>
closer = 'Mark.Shannon'
components = ['Interpreter Core']
creation = <Date 2021-07-09.10:53:40.343>
creator = 'Mark.Shannon'
dependencies = []
files = []
hgrepos = []
issue_num = 44590
keywords = ['patch']
message_count = 4.0
messages = ['397196', '398220', '398696', '413798']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'ncoghlan', 'vstinner', 'Mark.Shannon', 'pablogsal']
pr_nums = ['27077', '27525']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue44590'
versions = ['Python 3.11']
Activity
markshannon commentedon Jul 9, 2021
In https://bugs.python.org/issue44032 we moved most of the data in the frame stack, that is the locals, stack, and "specials" (globals, builtins, code etc), from the heap allocated stack to a (mostly) contiguous array in memory.
That offered some speed up due to better cache locality, and faster allocation of frame objects (they are now fixed size so can use a simple freelist).
However, data is still split between the stack allocated frame and the heap allocated frame.
We should move the remaining data to the stack and only allocate heap objects lazily when needed for tracebacks and the like. This should improve performance further by removing the vast majority of heap frame allocations and further improving locality of reference.
Not only does this have immediate performance benefits, it also paves the way for even better Python-to-Python calls by allowing stack frames to overlap and pass arguments with the minimal amount of copying and INCREF/DECREF pairs.
markshannon commentedon Jul 26, 2021
New changeset ae0a2b7 by Mark Shannon in branch 'main':
bpo-44590: Lazily allocate frame objects (GH-27077)
ae0a2b7
ncoghlan commentedon Aug 1, 2021
The newly linked pull request isn't actually for this ticket, it's for bpo-44800, a follow-up refactoring proposal related to the variable, struct field, and API naming schemes used for the new lighter weight execution frames.
However, the commit message and PR description refer back to this ticket as well, so the RoundUp automation picked it up.
vstinner commentedon Feb 23, 2022
I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".
encukou commentedon Apr 21, 2022
This PR changed
_PyFrameEvalFunctionto take_interpreter_frame(now_PyInterpreterFrame) rather thanPyFrameObject, but didn't update the documentation: https://docs.python.org/dev/c-api/init.html?highlight=_pyframeevalfunction#c._PyFrameEvalFunctionThe new struct is internal and undocumented. What should people who want to use their own function (per PEP-523) do?
vstinner commentedon Apr 21, 2022
The last time this API changed, I documented it here: https://docs.python.org/dev/whatsnew/3.9.html#id2
GH-88756: Update docs for PEP 523 eval function type. (GH-91788)
iritkatriel commentedon Sep 13, 2022
Is there anything left to do here?
vstinner commentedon Sep 15, 2022
The documentation was updated by the commit 5974827: https://docs.python.org/dev/c-api/init.html#c._PyFrameEvalFunction
I close the issue.