Sluggish call tree performance in threads with lots of samples

[mstange]

Steps to reproduce:

1. Load this profile: https://share.firefox.dev/32Vqug9
2. Use your arrow keys to change the selected row in the call tree.

Expected results: It should be snappy and fast.

Actual results: It is fairly sluggish.

Profile of sluggishness: https://share.firefox.dev/3lz1m5C

• 25% in getTimingsForCallNodeIndex (probably computing traced running time and implementation breakdown)
• 20% (10% + 10%) in getSamplesSelectedStates, used in activity graph drawing. It is strange that we compute this from two different stacks: once in the getSamplesSelectedStatesInFilteredThread selector, and then again in drawCanvas.
• 20% in computeActivityGraphFills. Probably not much we can do about this.

One big problem, as usual, is that the react render happens in the keydown handler, rather than from a requestAnimationFrame callback. So multiple keydowns are never batched.

┆Issue is synchronized with this Jira Task

[julienw]

One big problem, as usual, is that the react render happens in the keydown handler, rather than from a requestAnimationFrame callback. So multiple keydowns are never batched.

I wonder if React 18 helps with that 🤔

[mstange]

I wonder if React 18 helps with that 🤔

This document says no:

Note: React only batches updates when it’s generally safe to do. For example, React ensures that for each user-initiated event like a click or a keypress, the DOM is fully updated before the next event.