| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
…nGH-93383) Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com> Co-authored-by: Dennis Sweeney <36520290+sweeneyde@users.noreply.github.com>
|
@pablogsal and @nedbat This PR improves coverage performance on 3.11 by 5-7%. Using Ned's benchmarks # 3.11 branch at 1497d7fdefff8207b8ccde82e96b6f471416c284 Median for bm_sudoku.py, python3.11, cov=none: 10.476s Median for bm_sudoku.py, python3.11, cov=6.4.1: 69.124s Median for bm_spectral_norm.py, python3.11, cov=none: 9.072s Median for bm_spectral_norm.py, python3.11, cov=6.4.1: 72.143s # 3.11 co_code_cached Median for bm_sudoku.py, python3.11, cov=none: 10.363s Median for bm_sudoku.py, python3.11, cov=6.4.1: 64.726s Median for bm_spectral_norm.py, python3.11, cov=none: 9.325s Median for bm_spectral_norm.py, python3.11, cov=6.4.1: 69.713s An observation: bm_spectral_norm improved less than bm_sudoku because the size of its co_code is smaller. So the cost of getting a new one every time isn't as high. I think real-world code sizes are more likely to be like bm_sudoku or larger. So I'd guestimate we will see ~10% improvement in real-world code running coverage in 3.11. |
Sorry, something went wrong.
|
Unfortunately this means that whatever is making Python 3.11 slower with coverage, unfortunately is not only this :( Great investigation @Fidget-Spinner and thanks for working on this ♥️ I will try to review ASAP but it would be great if @markshannon @iritkatriel @brandtbucher or @ericsnowcurrently can take a look. |
Sorry, something went wrong.
There was a problem hiding this comment.
I'm on mobile right now (probably can't get to a computer today), but here are a few thoughts based on a first look:
Sorry, something went wrong.
|
I also ran the benchmarks using #93493:
It's a slight improvement, but isn't solving the problem. |
Sorry, something went wrong.
Yeah I'm aware. I sent this PR in because 10% improvement on macrobenchmarks is still something! Even cProfile slowed down by 60% when profiling code in 3.11. My hunch is that accessing the full PyFrameObject is signifcantly more expensive now in 3.11. However, I can't fix that because it's part of the tracing Py_tracefunc C API. |
Sorry, something went wrong.
Hm, it looks like in some cases this actually makes things a bit slower (perhaps due to the extra memory consumption)? Maybe we should pause this PR until @markshannon has finished reworking the line number calculations, which seem to be the bulk of the issue at this point. Or at least see if it slows down pyperformance at all before merging? |
Sorry, something went wrong.
When I benchmarked on the main/3.12 branch, it didn't make anything slower #93383 (comment). However, I agree on waiting for a while. When benchmarking with Ned's benchmarks, I saw a slowdown in bm_sudoku but no slowdown in bm_spectral_norm. I'm not sure what's up with that. |
Sorry, something went wrong.
|
When you're done making the requested changes, leave the comment: I have made the requested changes; please review again. |
Sorry, something went wrong.
Co-Authored-By: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
I have made the requested changes; please review again Mark. |
Sorry, something went wrong.
|
Thanks for making the requested changes! @markshannon: please review the changes made to this pull request. |
Sorry, something went wrong.
There was a problem hiding this comment.
Looks good.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
(cherry picked from commit d52ffc1)