Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create frame objects lazily when needed #88756

Closed
markshannon opened this issue Jul 9, 2021 · 8 comments
Closed

Create frame objects lazily when needed #88756

markshannon opened this issue Jul 9, 2021 · 8 comments
Assignees
@markshannon
Labels
3.11 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) pending The issue will be closed if no feedback is provided performance Performance or resource usage

Comments

@markshannon
Copy link
Member

BPO 44590
Nosy @gvanrossum, @ncoghlan, @vstinner, @markshannon, @pablogsal
PRs
  • bpo-44590: Lazily allocate frame objects #27077
  • WIP bpo-44800: Rename _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']
    @markshannon
    Copy link
    Member Author

    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 markshannon added the 3.11 only security fixes label Jul 9, 2021
    @markshannon markshannon self-assigned this Jul 9, 2021
    @markshannon markshannon added interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage 3.11 only security fixes labels Jul 9, 2021
    @markshannon markshannon self-assigned this Jul 9, 2021
    @markshannon markshannon added interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage labels Jul 9, 2021
    @markshannon
    Copy link
    Member Author

    New changeset ae0a2b7 by Mark Shannon in branch 'main':
    bpo-44590: Lazily allocate frame objects (GH-27077)
    ae0a2b7

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented 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
    Copy link
    Member

    I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @encukou
    Copy link
    Member

    encukou commented Apr 21, 2022

    This PR changed _PyFrameEvalFunction to take _interpreter_frame (now _PyInterpreterFrame) rather than PyFrameObject, but didn't update the documentation: https://docs.python.org/dev/c-api/init.html?highlight=_pyframeevalfunction#c._PyFrameEvalFunction

    The new struct is internal and undocumented. What should people who want to use their own function (per PEP-523) do?

    @encukou encukou reopened this Apr 21, 2022
    @encukou encukou mentioned this issue Apr 21, 2022
    Closed
    19 tasks
    @vstinner
    Copy link
    Member

    The last time this API changed, I documented it here: https://docs.python.org/dev/whatsnew/3.9.html#id2

    @markshannon markshannon mentioned this issue Apr 21, 2022
    Merged
    markshannon added a commit that referenced this issue Apr 21, 2022
    @markshannon
    GH-88756: Update docs for PEP 523 eval function type. (GH-91788)
    5974827
    @iritkatriel
    Copy link
    Member

    Is there anything left to do here?

    @iritkatriel iritkatriel added the pending The issue will be closed if no feedback is provided label Sep 13, 2022
    @vstinner
    Copy link
    Member

    The documentation was updated by the commit 5974827: https://docs.python.org/dev/c-api/init.html#c._PyFrameEvalFunction

    I close the issue.

    @zhuyifei1999 zhuyifei1999 mentioned this issue Oct 1, 2022
    Closed
    @safarmer safarmer mentioned this issue Nov 16, 2022
    Closed
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @markshannon markshannon

    Labels
    3.11 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) pending The issue will be closed if no feedback is provided performance Performance or resource usage
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    6 participants
    @vstinner @encukou @ncoghlan @iritkatriel @gvanrossum @markshannon