DAMP Perf regression in debugger stepIn test (+40%)
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(Not tracked)
People
(Reporter: jdescottes, Assigned: davidwalsh)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression)
Attachments
(1 file, 2 obsolete files)
424.62 KB,
image/png
|
Details |
Performance regression on the debuger stepIn test, most likely related to Bug 1576679 (Enable Inline Preview for all channels).
Alert summary:
== Change summary for alert #22876 (as of Wed, 28 Aug 2019 16:03:31 GMT) ==
Regressions:
34% damp custom.jsdebugger.stepIn.DAMP linux64-shippable-qr opt e10s stylo 386.42 -> 517.35
33% damp custom.jsdebugger.stepIn.DAMP windows10-64-shippable-qr opt e10s stylo 392.63 -> 520.27
30% damp custom.jsdebugger.stepIn.DAMP linux64-shippable opt e10s stylo 381.08 -> 494.02
9% damp custom.jsdebugger.stepOut.DAMP linux64-shippable opt e10s stylo 369.78 -> 402.31
3% damp custom.jsdebugger.stepOver.DAMP linux64-shippable-qr opt e10s stylo 259.25 -> 267.22
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=22876
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
After much profiling and investigation I've isolated the problem to the following line: https://searchfox.org/mozilla-central/source/devtools/client/debugger/src/actions/pause/inlinePreview.js#66
await parser.getScopes(frame.location);
The parser worker is taking the contents of step-in-test.js
, asking Babel to parse it, and return the scopes. Parsing and analyzing a 160kb file is causing the perf hit due to the about of time Babel requires. As I can't force Babel to go faster, we're in sort of a weird spot. We could find an alternative to Babel but that's obviously a much larger task.
A few ideas:
- Maybe we don't provide inline preview for files larger than a certain kb
- Greg mentioned that the profiler doesn't use workers because they can be slow; i.e. the time during postMessage calls is "wasted", whereas simply doing the work doesn't waste any time. We could try not using workers(?)
I don't think this is an issue with a simple quick fix.
Assignee | ||
Comment 3•5 years ago
|
||
It appears that Chrome uses acorn.js for parsing: https://github.com/acornjs/acorn
Assignee | ||
Comment 4•5 years ago
|
||
Profile for the StepIn test
You can see the "worker runnable" blocks are much larger with Preview on.
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
My console.logs make it obvious that the Scopes pane isn't waiting for inline preview to finish so generateInlinePreview
, which calls the await parser.getScopes(frame.location)
code, isn't holding up other parts of the debugger.
Comment 6•5 years ago
|
||
- Don't render if the props didn't change
- Avoid accessing
codeMirror
getter inside loops - Don't compute the same information twice
- Avoid memory allocations
I couldn't capture two identical enough profiles such that they can be easily compared.
Comment 7•5 years ago
|
||
Comment on attachment 9101662 [details]
perf(debugger): Optimize stepping
Revision D49477 was moved to bug 1550494. Setting attachment 9101662 [details] to obsolete.
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Closing as we understand the impact from the test was due to an new parser.getScopes call and do not intend to change that.
Updated•3 years ago
|
Description
•