-
Notifications
You must be signed in to change notification settings - Fork 129
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
Compute rect position and width from samples #210
Conversation
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.
This is a great change, thank you for taking the time to go through it! I left some comments inline, but in general the approach looks great.
I just realized that I've broken this code, which attempts to access Unfortunately I have no idea what it's for. I can't find any functionality that's missing. Help? |
Looks like GitHub got confused about your link. I think you're referring to inferno/src/flamegraph/flamegraph.js Lines 75 to 80 in 3e249a3
My read of that code is that it checks that the clicked rectangle is actually a sample box, and not just some other random |
Codecov Report
@@ Coverage Diff @@
## master #210 +/- ##
==========================================
- Coverage 90.08% 89.48% -0.60%
==========================================
Files 17 17
Lines 2239 2312 +73
==========================================
+ Hits 2017 2069 +52
- Misses 222 243 +21
Continue to review full report at Codecov.
|
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.
Will release this either today or tomorrow, thanks! 👍
Released in 0.10.4 |
This is my attempt at implementing a solution for #207. Recomputing the percentage position and width every time from the integer sample counts should keep floating-point errors to a minimum. Just that change altered the matched % reported during a search.
But I think the bigger discrepancy was coming from the regex search selecting samples that weren't on screen at all. Since I added the check for hidden objects everything seems quite reasonable.
I'm making this PR because a few days ago I zoomed way in to see the dashmap spinlock loop and the rectangles were hanging over each other. I don't have a reproducer of this on hand to verify, but boy does that seem like floating-point imprecision to me.