feat: invert call stack in flame graph to render as icicle graph

[cathaysia]

add a invert callstack checkbox.

before:

after:

fix #6077

[codecov]

Codecov Report

❌ Patch coverage is 94.56522% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.50%. Comparing base (a542753) to head (b894055).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
src/selectors/per-thread/stack-sample.ts	80.76%	5 Missing ⚠️
src/profile-logic/flame-graph.ts	96.89%	4 Missing ⚠️
src/app-logic/url-handling.ts	83.33%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6090   +/-   ##
=======================================
  Coverage   83.50%   83.50%           
=======================================
  Files         342      342           
  Lines       36522    36522           
  Branches    10233    10221   -12     
=======================================
  Hits        30497    30497           
  Misses       5597     5597           
  Partials      428      428           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cathaysia]

Hello, is anyone reviewing this PR? I don't have the permission to request a review.

[cathaysia]

https://firefox-profiler.netlify.app/

[mstange]

Unfortunately this implementation is too slow on large profiles. For example, clicking the "Invert call stack" checkbox on this flame graph causes the page to hang permanently:

https://deploy-preview-6090--perf-html.netlify.app/public/54908b38j3brzm4vw7mw3k3sqn3sf6vzfe95sxg/flame-graph/?globalTrackOrder=d59g1b7feac8x63402s6rx0mx4x3jthvilpnx5ux1qox2k&hiddenGlobalTracks=0wcewx6&profileName=Firefox%20Win%20Sp3%2015x%2020260304&thread=d&v=16

Furthermore, I think this view is only useful if most of the time is spent in a single leaf function. Once you have time spread over many different leaves, the inverted flame graph becomes less useful because all the root nodes will be very small boxes, and then their children are even smaller boxes.

However, what can be useful is the inverted flame graph for a single leaf function. In #5233 I'm prototyping a panel where you can select a function on the left side, and then see flame graphs for that function on the right side. When limited to a single function, computing the inverted flame graph can be done in reasonable time because the number of nodes in the tree is much more limited.

Here's an example:

https://deploy-preview-5233--perf-html.netlify.app/public/54908b38j3brzm4vw7mw3k3sqn3sf6vzfe95sxg/function-list/?funcListSections=descendants%2Cancestors&globalTrackOrder=d59g1b7feac8x63402s6rx0mx4x3jthvilpnx5ux1qox2k&hiddenGlobalTracks=0wcewx6&profileName=Firefox%20Win%20Sp3%2015x%2020260304&selectedFunc=23546&thread=d&v=17

[cathaysia]

Thanks for the large-profile test case. I reproduced the hang locally with the profile from the preview link: computing the inverted flame graph timing for thread d ran out of memory with an 8GB JS heap.

I pushed 1f13270a2 to address this:

• non-inverted flame graphs are back on the original FlameGraphRows + getFlameGraphTiming path, so they no longer go through the generic CallTree traversal;
• inverted flame graphs now use a dedicated timing builder based on CallNodeInfoInverted + CallTreeTimingsInverted, avoiding CallTree.getNodeData() and the display-layer traversal;
• the inverted builder prunes boxes narrower than 1 / 16384, because the flame graph has no horizontal zoom and those boxes cannot be meaningfully read or hovered even on very wide displays. This also avoids materializing huge invisible inverted subtrees.

With the same large profile / thread d, the selector now completes locally in about 1.6s and produces 242 rows / 42,238 boxes instead of OOMing.

I also added a regression test for the same-name-node case so the inverted tree does not combine unrelated call paths such as A -> B -> C and A -> C -> D into impossible paths.

[cathaysia]

Actually, I think it would be more appropriate to move the data processing part to WASM. Rust can precisely control memory, and Rust itself provides many tools for benchmarking.

[cathaysia]

🤖 This pull request will be closed in 15 days if there are no new non-automation comments.

tracked by #8

[mstange]

* inverted flame graphs now use a dedicated timing builder based on `CallNodeInfoInverted + CallTreeTimingsInverted`, avoiding `CallTree.getNodeData()` and the display-layer traversal;

* the inverted builder prunes boxes narrower than `1 / 16384`, because the flame graph has no horizontal zoom and those boxes cannot be meaningfully read or hovered even on very wide displays. This also avoids materializing huge invisible inverted subtrees.

Hmm, interesting. But in the large example, this causes a large gap on the side (maybe 15% of the width) because the positions of the rendered boxes are no longer affected by the (narrow) width of the discarded boxes. It also makes for a rather sluggish experience when you drag a preview selection in the timeline while you're looking at the inverted flame graph, because not much of the flame graph information can be reused across different timings.

In the meantime I've landed #6126 and #6128. Can you try out another approach where you make a lazy FlameGraphRowsInverted and FlameGraphTimingsInverted and see if the optimization from #6126 to only render visible rows is good enough to achieve acceptable performance?

[cathaysia]

Thanks for landing #6126 and #6128. I tested this again after rebasing locally onto current main, using the large profile from the earlier link (thread=d, local thread index 13).

A pure lazy FlameGraphTimingInverted / rows approach without tiny-node pruning was not sufficient for that profile. Building the inverted timing object was reasonable (~377ms), but materializing the first 40 visible rows still ran out of memory with an 8GB JS heap after around 110s. So the #6126 visible-row optimization helps avoid eagerly building the whole tree, but the visible shallow rows can still contain too much data.

I kept the lazy inverted timing shape, but kept the tiny-descendant pruning for boxes below 1 / 16384 of the width. The important change from the previous version is that skipped boxes still advance the horizontal position, so later boxes are not shifted left; this should avoid the large empty gap you observed.

With that version on the same profile, the inverted selector took ~523ms and materializing rows 0..39 took ~2.24s, producing 28,695 visible boxes without OOM. I also kept the upstream ConnectedFlameGraph / startsAtBottom structure from #6128.

[mstange]

Thanks, looks pretty good! Just two minor changes. The performance sounds good enough for now. Maybe in the future we can improve the "drag a preview selection" case by caching more information in the flame graph rows (but only compute that information lazily when the flame graph timings ask for it).

[mstange]

Looks good, thanks!