1797274 - Cover source-map loader performance on DAMP

Status: RESOLVED FIXED

(DevTools :: Debugger, task)

Description

[Alexandre Poirot [:ochameau]]

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.

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1797274 - [devtools] Track source-map gecko API performance.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 3

[Alexandre Poirot [:ochameau]]

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.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f64c07edfcfc
[devtools] Track source-map gecko API performance. r=perftest-reviewers,bomsy,jdescottes,sparky

Comment 5

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/f64c07edfcfc

Comment 6

[Julian Descottes [:jdescottes]]

== 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

[Julian Descottes [:jdescottes]]

Baseline update for simple open, probably a side effect from the new test?

Comment 8

[Julian Descottes [:jdescottes]]

Just a quick ping in case you didn't expect this change.

Comment 9

[Alexandre Poirot [:ochameau]]

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

[Julian Descottes [:jdescottes]]

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.