-
Notifications
You must be signed in to change notification settings - Fork 431
Fetch line numbers for Python frames lazily #31
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
Fetch line numbers for Python frames lazily #31
Conversation
aa31877 to
57f69c6
Compare
Pull request was converted to draft
|
Flipping this to Draft - this is subtly broken in a way that our test suite doesn't catch. I'll need to circle back to this - and add a new test... |
6cddca2 to
c20dd97
Compare
|
OK, I think this is now actually correct... And the new test case covers the problem that the original version of this had, so that we know we won't regress on it. |
fa73200 to
55b8367
Compare
55b8367 to
69de8a3
Compare
Up until now we've been greedily capturing the line number of each Python frame as we first encounter it, but this is unnecessarily inefficient. Since we've already been assuming that it's safe to call `PyFrame_GetLineNumber` without the GIL held (and we'd already need to change this code should that assumption become false in a future CPython version), we can delay calculating the Python line number until we're about to emit the frame. Since many frames are entered without ever being emitted (because no allocation is performed under them), this drastically reduces the number of calls to `PyFrame_GetLineNumber`, which is a deceptively slow function. Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
If we only update line numbers on Python frame pushes and pops we'll get this wrong, as the line number to be tracked changes in between two allocations without us ever entering or exiting a Python function. Signed-off-by: Matt Wozniski <godlygeek@gmail.com>
69de8a3 to
b50d319
Compare
|
Experiments executed for With this PRBaselineThis means that in general the most we can save (that we are indeed saving it) is 0.39% of the total runtime (this is assuming no For the case where PRBaselineThis means that in the latter we are saving ~2% maximum. This is consistent with the timing results of PRBaselineThat is around 3.5% of the difference. |
Up until now we've been greedily capturing the line number of each
Python frame as we first encounter it, but this is unnecessarily
inefficient. Since we've already been assuming that it's safe to call
PyFrame_GetLineNumberwithout the GIL held (and we'd already need tochange this code should that assumption become false in a future CPython
version), we can delay calculating the Python line number until we're
about to emit the frame. Since many frames are entered without ever
being emitted (because no allocation is performed under them), this
drastically reduces the number of calls to
PyFrame_GetLineNumber,which is a deceptively slow function.