I was trying to inspect DevTools UI. Browser toolbox panels loaded very slowly but were OK after the initial delay.

Later, the whole UI froze for seconds: https://share.firefox.dev/3fhvKvR

addSources/< and insertSourceActors/< both lead to getDisplayedSources< where most time is spend. Maybe instrumenting those with markers (bug 1634467) might help to dig into which kind of sources are being added.

Oof, that's rough. I think what I see in that is unfortunately just us having a lot of sources, which likely points at us needing to revisit how we calculate and render the sources tree.

Out of curiosity Harald, do you think the Nightly you were debugging had a lot of tabs open, was this your normal-usage Nightly? I'm wondering if maybe there was a particularly large number of threads, which could have contributed to getDisplayedSources being extra busy.

It's hard to be 100% sure here, but what I don't see is much time in getAllDisplayedSources, so at least our optimizations there seem to have helped a bit?

I think we just need to step back and rethink these selectors, because clearly right now they do too much computation, even if we do our best to memoize it.

Out of curiosity Harald, do you think the Nightly you were debugging had a lot of tabs open, was this your normal-usage Nightly?

This was in my default profile, with 30 tabs or so open (pinned tabs: 3 slack instances, riot, gcal, gmail; heavy hitters with scripts)

Tracking for Fission Nightly milestone M6c. We should fix browser hangs before enabling Fission in Nightly!

Adding dt-fission whiteboard tag to DevTools bugs that mention Fission or block Fission meta bugs but don't already have a dt-fission whiteboard tag.

Moving dt-fission bugs to Fission MVP.

Bulk change of all bugs with whiteboard tag of dt-fission to Fission MVP milestone.

Moving old "dt-fission" bugs to "dt-fission-future" because they don't block Fission MVP.

Here is a recent record when opening the debugger against a long lasting firefox instance:
https://share.firefox.dev/3FUmxrN

The debugger takes 15s to settle, on this:

• We still see getDisplayedSources, but only around 360ms
• disableEmptyLines 1400ms
• getRelativeUrl 700ms
• addToTree 600ms

The main overload comes from the fact that we try to display the sources from all the content processes,
this include all JSMs/XPCOM, but also all web pages sources...

It might be relevant to have the multiprocess feature possibly disabled by default and only display all processes on-demand.

All the time spent in the SourceTree might have been worth, but still far from being enough.

When opening the inspector or the netmonitor while the debugger is opened, I'm observing massive slowdown, making the inspector take more than one minute to open:
https://share.firefox.dev/3bhiXwp

We spent all the time creating sources in the debugger.
No idea what are all these sources and why it takes so long in the debugger to process them.

With bug 1777203, the performance of the debugger in the Browser Toolbox "IRL" are way better:
https://share.firefox.dev/3JFDKqy

Compared to a 1 minute freeze or so, now the debugger opens in 3 to 5 seconds.
It no longer freezes, but you can see that the debugger takes a few seconds before showing any source.
It actually seems to display all sources in one go.
It would be nice if we were showing the main thread sources right away.

A couple of things stands out from this profile:

• sort usages from sources-tree reducer takes 135ms
  https://searchfox.org/mozilla-central/search?q=sort%28&path=reducers%2Fsources-tree&case=false&regexp=false
  We might be able to add the items sorted instead of sorting the whole array each time

• clearSourceActorMapURL takes 100ms, which seems a lot for such naive action:
  https://searchfox.org/mozilla-central/rev/c0bed29d643393af6ebe77aa31455f283f169202/devtools/client/debugger/src/reducers/source-actors.js#61-72
  May be we call this on more sources than what we expect?
  We seem to call this an handful times for a couple of sources coming from treeherder.
  The same URLs seem to be loaded many times and trigger this.

• getDisplayURL takes 90ms, which still looks like a lot for parsing URL...