I hope that other tools beyond Fil and Fil4prod start adopting these improvements [icicle mode, showing more text, better colors, line numbers], and look forward to seeing what further improvements we can find to these visualizations.
I’ve been using Speedscope for a while, and I think it has had all of these features for a while. Instead of right-aligning text but still truncating it, it just allows you to zoom in. It doesn’t include source code, but for me function names are actually more readable.
Isn’t the saturation=width a bit misleading though? If you have a loop which calls a short foo() thousands of times, each one will be very pale. But if you choose random colour per-function while keeping saturation, that allows spotting common patterns.
They seem to work well in different scenarios rather than one being better than the other.
No, in a flamegraph the X axis isn’t time. So if you have lots of calls to a single function, they will end up merged into one single (long) frame if you’re profiling performance. (I will try to update the page tomorrow to make that explicit.)
Update: Or rather, the X axis width is a percentage (of memory allocations, or time if this is performance), but the order is not meaningful. So identical callstacks get combined into a longer frame.
In this specific flamegraph it isn’t, but you can generate an over-time samples based flamegraph too. Like Ruby stackprof does in raw mode for example.
But even here the difference still holds for cases with auto-generated structures - think large parser / visitor pattern with small things hanging off the different types of nodes.
There are reverse flamegraphs that start from the opposite site of the stack, for places like recursion where you have repeating pattern at bottom of the stack but the top differs. Fil generates both in its reports.
In any case: the point is not so much that the default coloring scheme for flamegraphs is useless, it’s just that I believe it’s a bad default.
I’ve been using Speedscope for a while, and I think it has had all of these features for a while. Instead of right-aligning text but still truncating it, it just allows you to zoom in. It doesn’t include source code, but for me function names are actually more readable.
It doesn’t do the colo-saturation-matches-width, though, which I think is the most important change.
Isn’t the saturation=width a bit misleading though? If you have a loop which calls a short foo() thousands of times, each one will be very pale. But if you choose random colour per-function while keeping saturation, that allows spotting common patterns.
They seem to work well in different scenarios rather than one being better than the other.
No, in a flamegraph the X axis isn’t time. So if you have lots of calls to a single function, they will end up merged into one single (long) frame if you’re profiling performance. (I will try to update the page tomorrow to make that explicit.)
Update: Or rather, the X axis width is a percentage (of memory allocations, or time if this is performance), but the order is not meaningful. So identical callstacks get combined into a longer frame.
In this specific flamegraph it isn’t, but you can generate an over-time samples based flamegraph too. Like Ruby stackprof does in raw mode for example.
But even here the difference still holds for cases with auto-generated structures - think large parser / visitor pattern with small things hanging off the different types of nodes.
There are reverse flamegraphs that start from the opposite site of the stack, for places like recursion where you have repeating pattern at bottom of the stack but the top differs. Fil generates both in its reports.
In any case: the point is not so much that the default coloring scheme for flamegraphs is useless, it’s just that I believe it’s a bad default.
Interesting. This looks very much like Catapult: https://chromium.googlesource.com/catapult/+/HEAD/tracing/README.md