-
Notifications
You must be signed in to change notification settings - Fork 18
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
Fix slow pprof for Alloc profiles: Use integer keys; stop stringifying StackFrames (it's expensive) #86
Conversation
…stringifying the frame!
Codecov Report
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. @@ Coverage Diff @@
## main #86 +/- ##
=======================================
Coverage ? 96.59%
=======================================
Files ? 3
Lines ? 294
Branches ? 0
=======================================
Hits ? 284
Misses ? 10
Partials ? 0 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
46ef06a
to
d87d0f2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems legit, thanks!
In #70, we fixed the issue in #69 (multiple stackframes hashing to the same thing) by stringifying the stack frame. This turns out to be terribly, terribly slow.
This PR instead fixes the issue by manually constructing a unique Location for each frame in the stack, by pairing the unique function ID with the line number of the frame. This is what is meant by a location: a function + a line number, so that should be a perfectly suitable unique location key.
I also added a rigorous regression-testing file, which compares the profiles produced by any branch to the profiles produced on
main
. This helped me be confident in this change, and should help us prevent any issues in the future.