Skip to content

Create frame objects lazily when needed #88756

Closed
Closed
Create frame objects lazily when needed#88756
Assignees
markshannon
Labels
3.11only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)pendingThe issue will be closed if no feedback is providedperformancePerformance or resource usage

Description

@markshannon
markshannon
opened on Jul 9, 2021
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']

    Activity

    1. markshannon commented on Jul 9, 2021

      @markshannon
      markshannon
      on Jul 9, 2021
      MemberAuthor

      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.

    2. markshannon
      added
      3.11only security fixes
      on Jul 9, 2021
    3. markshannon
      self-assigned this
      on Jul 9, 2021
    4. markshannon
      added
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      performancePerformance or resource usage
      3.11only security fixes
      on Jul 9, 2021
    5. markshannon
      self-assigned this
      on Jul 9, 2021
    6. markshannon
      added
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      performancePerformance or resource usage
      on Jul 9, 2021

    7. markshannon commented on Jul 26, 2021

      @markshannon
      markshannon
      on Jul 26, 2021
      MemberAuthor

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

    8. markshannon
      closed this as completedon Jul 29, 2021
    9. markshannon
      closed this as completedon Jul 29, 2021

    10. ncoghlan commented on Aug 1, 2021

      @ncoghlan
      ncoghlan
      on Aug 1, 2021
      Contributor

      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.

    11. vstinner commented on Feb 23, 2022

      @vstinner
      vstinner
      on Feb 23, 2022
      Member

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

    12. ezio-melotti
      transferred this issue fromon Apr 10, 2022

    13. encukou commented on Apr 21, 2022

      @encukou
      encukou
      on Apr 21, 2022
      Member

      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?

    14. encukou
      reopened this on Apr 21, 2022

    15. vstinner commented on Apr 21, 2022

      @vstinner
      vstinner
      on Apr 21, 2022
      Member

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

    16. markshannon
      added a commit that references this issue on Apr 21, 2022

      GH-88756: Update docs for PEP 523 eval function type. (GH-91788)

      5974827

    17. iritkatriel commented on Sep 13, 2022

      @iritkatriel
      iritkatriel
      on Sep 13, 2022
      Member

      Is there anything left to do here?

    18. iritkatriel
      added
      pendingThe issue will be closed if no feedback is provided
      on Sep 13, 2022

    19. vstinner commented on Sep 15, 2022

      @vstinner
      vstinner
      on Sep 15, 2022
      Member

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

      I close the issue.

    20. gvanrossum
      closed this as completedon Sep 15, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    3.11only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)pendingThe issue will be closed if no feedback is providedperformancePerformance or resource usage

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions