bpo-44590: Lazily allocate frame objects#27077
Conversation
…a frame, except for the locals.
…to tstate.pyframe as preparation for lazily created frames.
… object outlives stack invocation.
…has been deleted.
…t introspects frames.
pablogsal
left a comment
There was a problem hiding this comment.
LGTM Great job!
Let's run the buildbots and land!
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @markshannon for commit e8476b2 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
|
The failures on buildbot/AMD64 Windows10 PR look like something is wrong with that machine. |
Sorry, something went wrong.
|
One consequence of this change is that the code is now quite confusing, since the term "frame" is used ambiguously to refer to both frame objects and interpreter frames (specifically, the |
Sorry, something went wrong.
|
The generator code uses |
Sorry, something went wrong.
|
I've posted a proposed internal API refactoring design here: https://bugs.python.org/issue44800 |
Sorry, something went wrong.
|
And the PR implementing that proposed refactoring is up at #27525 |
Sorry, something went wrong.
This PR:
For most calls to Python functions, we can get the necessary memory for a stack frame by just bumping a pointer.
When we do need a frame object, for tracebacks and the like, it is lazily allocated.
According to my benchmarking run this PR produces a maximum speedup of 31% with a mean of 7%!
The performance numbers are suspiciously good.
If someone could run the comparison on their machine that would be much appreciated.
https://bugs.python.org/issue44590