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
PyCode_GetCode
could be faster
#93382
Labels
3.12
interpreter-core
Interpreter core (Objects, Python, Grammar, and Parser dirs)
performance
Performance or resource usage
Comments
PyCode_GetCode
is really slowPyCode_GetCode
could be faster
Fidget-Spinner
added a commit
that referenced
this issue
Jun 3, 2022
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com> Co-authored-by: Dennis Sweeney <36520290+sweeneyde@users.noreply.github.com>
Fidget-Spinner
added a commit
to Fidget-Spinner/cpython
that referenced
this issue
Jun 4, 2022
…nGH-93383) Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com> Co-authored-by: Dennis Sweeney <36520290+sweeneyde@users.noreply.github.com>
Fidget-Spinner
added a commit
that referenced
this issue
Jun 24, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
3.12
interpreter-core
Interpreter core (Objects, Python, Grammar, and Parser dirs)
performance
Performance or resource usage
This potentially affects tools like coverage.py. It also means anything using
co_code
in CPython frequently is significantly slower. Note that pre-3.11, most code would assume this operation is O(1), so it's probably called more often than we expect.We should lazily initialise a hidden
_co_code
field and cache it there. Currently it creates a fresh bytes object on eachco_code
access. This is at best O(n).The text was updated successfully, but these errors were encountered: