https://bugs.kde.org/show_bug.cgi?id=428689
--- Comment #2 from Andrew Somerville <andy.somervi...@gmail.com> --- > Would you think it should look like this: > > [1x 100b] > [a ] [1x 200b ] > [b ] [1x 200b ] [1x 100b] > [c ] Yeah, that's almost exactly what I was thinking. In this example only the break-out/histogram of `c`'s allocations (next to `b`) is particularly meaningful since the others only have a single allocation, but you could imagine this same function path being traversed many times with different allocation sizes happening each time. Currently all those are aggregated into a single flame graph with a total outstanding memory at the moment of peak memory use, but with the allocation pseudo-histogram broken out as you have above, it would be clear whether there were many small allocations or few large ones. (For good measure the call counts of each function might also be nice) With regard to the second idea, I'm afraid my understanding of some of the foundational stuff is a little thin. My naive thought would be that it might need to be heuristic. Perhaps seeing two successive frames matching a `operator new` regex and capturing their size argument, one could divide one by the other and deduce a size. But that's a shot in the dark. And I can certainly make a separate bug report if it's helpful. -- You are receiving this mail because: You are watching all bug changes.
