Heavy Angular app slows Debugger and Console load
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(firefox73 fixed)
Tracking | Status | |
---|---|---|
firefox73 | --- | fixed |
People
(Reporter: Harald, Assigned: bhackett1024)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
- Open Debugger on https://app.frontapp.com/signin
- Wait for Sources to load
- 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.
getBreakpointPositions
triggers several_addScriptBreakpointPositions
: Each blocking the content process for 700ms.
- Some time in
DelazifyScript
- 25% in GC because of
js::WeakMap
injs::Debugger::trace
.
_findDebuggeeScripts
: 600ms, mostly GC (99%)
Comment 1•5 years ago
|
||
CC Brian, I wonder if there's anything we can do here to speed this up?
Assignee | ||
Comment 2•5 years ago
|
||
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.
Reporter | ||
Comment 3•5 years ago
|
||
Brian, should we brake those out into separate enhancements or would you work on the in this bug?
Assignee | ||
Comment 4•5 years ago
|
||
(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.
Assignee | ||
Comment 5•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 6•5 years ago
|
||
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.
Comment 8•5 years ago
|
||
bugherder |
Reporter | ||
Updated•5 years ago
|
Description
•