Description

markshannon

opened on Jul 9, 2021

Issue body actions

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

   on Jul 9, 2021

   MemberAuthor

   More actions

   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 fixesonly 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)(Objects, Python, Grammar, and Parser dirs)

   performancePerformance or resource usagePerformance or resource usage

   3.11only security fixesonly 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)(Objects, Python, Grammar, and Parser dirs)

   performancePerformance or resource usagePerformance or resource usage

   on Jul 9, 2021
7. markshannon commented on Jul 26, 2021

   

   markshannon

   on Jul 26, 2021

   MemberAuthor

   More actions

   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

    on Aug 1, 2021

    Contributor

    More actions

    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

    on Feb 23, 2022

    Member

    More actions

    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

    on Apr 21, 2022

    Member

    More actions

    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

    on Apr 21, 2022

    Member

    More actions

    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

    on Sep 13, 2022

    Member

    More actions

    Is there anything left to do here?
18. iritkatriel

    added

    pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided

    on Sep 13, 2022
19. vstinner commented on Sep 15, 2022

    

    vstinner

    on Sep 15, 2022

    Member

    More actions

    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
21. dhansen-nvidia

    added a commit that references this issue on Nov 12, 2026

    [None][perf] Run the executor loop under a CPython frame-stack reserve

    632ad06

Issue actions