Optimize the parser worker computations
Categories
(DevTools :: Debugger, enhancement)
Tracking
(firefox120 fixed)
| Tracking | Status | |
|---|---|---|
| firefox120 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
Attachments
(8 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
The parser worker does heavy computations based on Babel's output.
There is a few things we can tweak to avoid some allocations and speedup some code.
| Assignee | ||
Comment 1•2 years ago
|
||
On bug 1843454 STR, symbols.identifiers is a 100M large array.
So all these intermediate array cause a serious amount of short-lived arrays.
| Assignee | ||
Comment 2•2 years ago
|
||
We were creating them and later filtering them out.
Also getUniqueIdentifiers was duplicating a possibly 100M+ large array...
| Assignee | ||
Comment 3•2 years ago
|
||
| Assignee | ||
Comment 4•2 years ago
|
||
Computing the expression would involve calling Babel's generate method on the AST node,
which is expansive. But we rarely read this attribute.
| Assignee | ||
Comment 5•2 years ago
|
||
This represents lots of patches... but with a quite small improvement on DAMP:
https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=8b23302336ab969a2d1c506bf633fa1287157536&originalSignature=4763542&newSignature=4763542&framework=12&application=firefox&originalRevision=43c06a822362f1cdcbd63b074ccabc96f4e85fd6&page=1&showOnlyConfident=1
But hopefully, this will reduce GC overhead, which isn't so well covered on DAMP.
For some reason, on DAMP, we are rarely blocked by a pending GC in the parser worker. Whereas IRL, this is very common and can delay very significantly variable preview.
| Assignee | ||
Comment 6•2 years ago
|
||
When opening the debugger against http://techno-barje.fr/fission/large-bundle/ and reloading the page once,
we can see significant different in GC.
Profile without any of these patches:
https://share.firefox.dev/46Q7Ged
Profile with all these patchs:
https://share.firefox.dev/3rSG09q
We move from 10s+ GC in the parser worker down to 7s.
The most important change is this 4.5s pause doing GC without the patches after we start reloading the page.
This delays the computation of the new original file AST.
This pause, with all these patches is down to 1.3s.
| Assignee | ||
Comment 7•2 years ago
|
||
There might be more.
While doing that, document the objects being stored and their precise usage.
Updated•2 years ago
|
| Assignee | ||
Comment 8•2 years ago
|
||
As imports are only used for knowing if that's a react module...
We could avoid a bunch of intermediate objects by computing right away if we have a react import.
| Assignee | ||
Comment 9•2 years ago
|
||
As callExpressions are only used for knowing if that's a react module...
We could avoid a bunch of intermediate objects by computing right away if we have a react import.
| Assignee | ||
Comment 10•2 years ago
|
||
This attribute isn't used. Member expressions are only used by findBestMatchExpression.
| Assignee | ||
Comment 11•2 years ago
|
||
Actually, lazifying both expression for object expression and snippet brings even more improvements:
https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=e7bddc6bd6b0a5af5ddf9dff0d8e9fece7cde6ef&originalSignature=4763542&newSignature=4763542&framework=12&application=firefox&originalRevision=43c06a822362f1cdcbd63b074ccabc96f4e85fd6&page=1&showOnlyConfident=1
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/03a7c78f3dd2
https://hg.mozilla.org/mozilla-central/rev/6d0ed4d665f2
https://hg.mozilla.org/mozilla-central/rev/319d91a930d9
https://hg.mozilla.org/mozilla-central/rev/0878e0610fb7
https://hg.mozilla.org/mozilla-central/rev/68eb34ac9527
https://hg.mozilla.org/mozilla-central/rev/b7ff0d21e05a
https://hg.mozilla.org/mozilla-central/rev/a86d62a27a74
https://hg.mozilla.org/mozilla-central/rev/d1c21df521be
Comment 14•2 years ago
|
||
== Change summary for alert #40006 (as of Thu, 19 Oct 2023 23:28:41 GMT) ==
Improvements:
| Ratio | Test | Platform | Options | Absolute values (old vs new) |
|---|---|---|---|---|
| 9% | damp custom.jsdebugger.open-large-minified-file.full-selection.DAMP | linux1804-64-shippable-qr | e10s fission stylo webrender | 5,737.60 -> 5,226.79 |
| 7% | damp custom.netmonitor.reload.DAMP | windows10-64-shippable-qr | e10s fission stylo webrender-sw | 388.51 -> 361.60 |
| 6% | damp custom.jsdebugger.open-large-minified-file.full-selection.DAMP | windows10-64-shippable-qr | e10s fission stylo webrender | 3,895.37 -> 3,665.49 |
| 6% | damp custom.jsdebugger.open-large-minified-file.full-selection.DAMP | windows10-64-shippable-qr | e10s fission stylo webrender-sw | 3,863.30 -> 3,635.60 |
| 6% | damp custom.netmonitor.open.DAMP | linux1804-64-shippable-qr | e10s fission stylo webrender | 283.92 -> 268.12 |
| ... | ... | ... | ... | ... |
| 4% | damp custom.jsdebugger.pretty-print.reload-and-pause.DAMP | linux1804-64-shippable-qr | e10s fission stylo webrender | 11,545.80 -> 11,124.38 |
For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=40006
Description
•