-
Notifications
You must be signed in to change notification settings - Fork 125
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
ctrl+f search sometimes reports a very incorrect Matched percentage #207
Comments
Bumping up the value in the I think this is a rounding problem; the flamegraph I've encountered this on has 22 threads and I'm zoomed into a function that is 0.15% of all cycles (on this thread). But there are 5,934 cycles in this function, so I feel like we shouldn't have rounding issues. |
Hmm, I think removing the percentages might be tricky, though you might be able to inject the sample count using a |
I think this was fixed by #210. But I haven't been fiddling with the really complicated flamegraphs that reproduce this. If I find it again I'll reopen this. |
Ah, yes, I think you're right. Thanks for coming to check back in! |
I just ran into a seriously egregious case in an internal codebase. I'm zoomed into a function that has a a bug (that I just wrote) that causes it to mostly create and extend
Vec
s. If I ctrl+f foralloc::alloc
, the flamegraph tells me 35.3% of samples match. That looks quite wrong. But this program uses the default allocator, so I ctrl+f for__GI___libc
which matches what all the allocator functions call. The flamegraph says 72.3% of samples match, and looks correct.I have no idea what is going on here. I'm trying to reproduce with something that I can upload. No luck just yet.
The text was updated successfully, but these errors were encountered: