Cover source-map loader performance on DAMP
Categories
(DevTools :: Debugger, task)
Tracking
(firefox108 fixed)
Tracking | Status | |
---|---|---|
firefox108 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Performance of the source-map parsing and lookup can be a competitive argument.
It would be nice to keep track of its improvements/regression over time.
For now it is indirectly tracked by Debugger tests, involving a sourcemapped test page.
But this test page, based on react app simplest example is probably too light and small regression may be hidden by the high cost of rendering in the debugger frontend.
Assignee | ||
Comment 1•2 years ago
|
||
Updated•2 years ago
|
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::Debugger' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Assignee | ||
Comment 3•2 years ago
|
||
I opened bug 1797690 followup in order to focus here in landing early a DAMP test against the "source map loader" layer that is in mozilla-central.
This is also called Toolbox source map service.
This wraps the source-map package and add some code to fetch sourcemap file content and pass it to the source-map API.
I would like to land this first test early so that we can access to the performance impact of the current ongoing source-map package refactoring.
Updated•2 years ago
|
Comment 5•2 years ago
|
||
bugherder |
Comment 6•2 years ago
|
||
== Change summary for alert #35981 (as of Sat, 05 Nov 2022 02:25:33 GMT) ==
Regressions:
Ratio | Test | Platform | Options | Absolute values (old vs new) |
---|---|---|---|---|
15% | damp simple.netmonitor.open.DAMP | macosx1015-64-shippable-qr | e10s fission stylo webrender | 133.47 -> 153.15 |
15% | damp simple.netmonitor.open.DAMP | macosx1015-64-shippable-qr | e10s fission stylo webrender-sw | 133.69 -> 153.13 |
12% | damp simple.netmonitor.open.DAMP | windows10-64-shippable-qr | e10s fission stylo webrender-sw | 148.66 -> 167.19 |
12% | damp simple.netmonitor.open.DAMP | windows10-64-shippable-qr | e10s fission stylo webrender | 150.46 -> 167.93 |
8% | damp simple.netmonitor.open.DAMP | linux1804-64-shippable-qr | e10s fission stylo webrender-sw | 176.44 -> 190.62 |
For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=35981
Comment 7•2 years ago
|
||
Baseline update for simple open, probably a side effect from the new test?
Comment 8•2 years ago
|
||
Just a quick ping in case you didn't expect this change.
Assignee | ||
Comment 9•2 years ago
|
||
I wasn't expecting an impact, but yes that's probably just the source-map test being quite intense and simply grow the GC size for the tests running after.
We might also leak some decent amount of memory which may make things even worse.
There is one thing that disturbs me. Why netmonitor.simple? Why only this one, and not only the simple.debugger, which should be the test run right after source-map.
Comment 10•2 years ago
|
||
Good question. Simple.debugger open takes around 500ms whereas netmonitor.simple.open was at 150ms. So if we have a flat 20ms regression, it might not be detected in the debugger tests. Although looking at the charts, I don't see any bump either.
Description
•