ctrl+f search sometimes reports a very incorrect Matched percentage

[saethlin]

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 Vecs. If I ctrl+f for alloc::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.

[saethlin]

Bumping up the value in the toFixed in format_percent fixes this. Is there a way to get around the formatting and re-parsing of integers inside the SVG? I feel like working with the number of samples everywhere should be more effective, no?

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.

[jonhoo]

Hmm, I think removing the percentages might be tricky, though you might be able to inject the sample count using a data- attribute which the JavaScript code can then pick up on?

[saethlin]

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.

[jonhoo]

Ah, yes, I think you're right. Thanks for coming to check back in!