Closed Bug 1598180 Opened 5 years ago Closed 5 years ago

Heavy Angular app slows Debugger and Console load


(DevTools :: Debugger, defect, P2)



(firefox73 fixed)

Firefox 73
Tracking Status
firefox73 --- fixed


(Reporter: Harald, Assigned: bhackett1024)


(Blocks 2 open bugs)



(1 file)

  1. Open Debugger on
  2. Wait for Sources to load
  3. Switch to Console

AR: 500ms delay to load Console

The console seems to wait on data from the content process, which is blocked with Debugger churn.

  1. getBreakpointPositions triggers several _addScriptBreakpointPositions: Each blocking the content process for 700ms.
  • Some time in DelazifyScript
  • 25% in GC because of js::WeakMap in js::Debugger::trace.
  1. _findDebuggeeScripts: 600ms, mostly GC (99%)

CC Brian, I wonder if there's anything we can do here to speed this up?

Flags: needinfo?(bhackett1024)

I haven't been able to reproduce this locally (the console starts up quickly, should I login to the site as well?), but looking at the profile and the source there are several potential performance pitfalls here. The biggest one is that we can ask for the breakpoint positions on a source multiple times (if there are many original sources corresponding to different parts of the generated source), and if any scripts have been GC'ed then each time we will reparse the entire generated source and generate a new batch of scripts to examine. This is expensive, and can generate a lot of garbage for the GC to clean up. It's easy to memoize this computation and we should do that.

Beyond that, there is another pitfall where calling dbg.findScripts() with a line number in the query will trigger delazification of every script in the source, which will also be really expensive on a huge generated source. We don't use a line number in the query when getting breakpoint positions, but we do in other places, and I can't tell if those are being called here (it would be really sweet to have a web replay recording associated for the profile, so the page's behavior can be examined in minute detail).

In general, the source actor isn't very well optimized for dealing with huge generated sources. Every time we have to get some of the scripts in the source we ask the debugger for them, and every time we do that the debugger has to scan every script in the realm. It would be much nicer if the source actor could do this query once, and index the results so that it can quickly find scripts in certain parts of the source. I'll see if I can do that, which would address the two points above as well.

Brian, should we brake those out into separate enhancements or would you work on the in this bug?

(In reply to :Harald Kirschner :digitarald from comment #3)

Brian, should we brake those out into separate enhancements or would you work on the in this bug?

I think it's simplest to work here, though the fix will need to be verified afterwards because I haven't reproduced the original problem myself.

Flags: needinfo?(bhackett1024)
Assignee: nobody → bhackett1024

This patch avoids calling dbg.findScripts() or reparsing more than once for a source, by remembering the results of these computations on the actor. Making indexing very fast in all cases is tricky because of the complexity of the queries, which provide a range of line/columns. Instead, with this patch we only store the root scripts we find (there will only be one if nothing in the source has been GC'ed), and descend through the scripts to add any children that match. This allows us to avoid looking through all the child scripts of the outer functions that large generated files tend to contain for each original file.

Before this patch and on the page in comment 0, if I open up the debugger and view various Webpack files, getBreakpointPositions requests are dispatched which often take 300-500 ms for the server to handle. This patch reduces these times to 1-10 ms.

Pushed by
Optimize searching for matching scripts in a source, r=loganfsmyth.
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 73
Depends on: 1612931
No longer depends on: 1612931
Regressions: 1612931
Regressions: 1622153


Regressions: 1613376, 1627712
You need to log in before you can comment on or make changes to this bug.