Closed Bug 1833464 Opened 2 years ago Closed 2 years ago

Main thread parsing / delazification is slowing down some sp3 subtests

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
116 Branch
Tracking Flags:
Tracking Status
firefox116 --- fixed

People

(Reporter: mstange, Assigned: denispal)

References

(Blocks 1 open bug)

Details

(Keywords: perf-alert, Whiteboard: [sp3])

Attachments

(1 file)

Bug 1833464: Apply delazify strategy to off thread module compilations r=nbp!
48 bytes, text/x-phabricator-request
Details | Review

We see JS parsing / bytecode generation happening on the main thread during the Speedometer 3 subtests TodoMVC-Angular and TodoMVC-Backbone.

It would be nice if we could tweak our off-main-thread parsing heuristics so that we do this work on a background thread.

Angular profile: https://share.firefox.dev/459leBt
Backbone profile: https://share.firefox.dev/3ByBn5U

We can close the Angular gap by doing a full parse on every script, including ones we parse on the main thread.

Still looking into Backbone.

(In reply to Denis Palmeiro [:denispal] from comment #1)

We can close the Angular gap by doing a full parse on every script, including ones we parse on the main thread.

Interesting! It's worth investigating what scripts (and why) we're parsing on the main thread. Full parsing is slower than syntax parsing so there might be ways to address this that are less risky perf-wise.

Stupid question, would off-thread delazification help by providing a shorter load-time between the resource load and its execution?
Thus reducing the total execution time, in addition to improving the score.

(In reply to Jan de Mooij [:jandem] from comment #2)

(In reply to Denis Palmeiro [:denispal] from comment #1)

We can close the Angular gap by doing a full parse on every script, including ones we parse on the main thread.

Interesting! It's worth investigating what scripts (and why) we're parsing on the main thread. Full parsing is slower than syntax parsing so there might be ways to address this that are less risky perf-wise.

For angular, it seems to be this script https://speedometer-preview.netlify.app/resources/todomvc/architecture-examples/angular/dist/runtime.27845ceb5aedcb1f.js that is parsed lazily. We currently only full parse scripts that are compiled off the main thread, and this script is not because it only has 1064 characters and fails the 5000 character heuristic required..

(In reply to Nicolas B. Pierron [:nbp] from comment #3)

Stupid question, would off-thread delazification help by providing a shorter load-time between the resource load and its execution?
Thus reducing the total execution time, in addition to improving the score.

I tried a run that disables the tiny script heuristic and it doesn't seem to help much unfortunately.
If full parsing scripts <= 5000 chars is not too expensive, I actually wonder if we should just full parse these too even on the main thread? Caching the bytecode in memory would also help.

If full parsing scripts <= 5000 chars is not too expensive, I actually wonder if we should just full parse these too even on the main thread?

This seems worth testing, with a close look at pageload.

I was wrong. Looking closer at this, it looks like we are missing full parse on off thread module compilations and this is where the opportunity is, specifically for these files:

Module: https://speedometer-preview.netlify.app/resources/todomvc/architecture-examples/angular/dist/polyfills.55e452bef9dff314.js, length = 33861
Module: https://speedometer-preview.netlify.app/resources/todomvc/architecture-examples/angular/dist/main.47f1891b70562df3.js, length = 227361

Assignee: nobody → dpalmeiro
Status: NEW → ASSIGNED

(In reply to Denis Palmeiro [:denispal] from comment #8)

I was wrong. Looking closer at this, it looks like we are missing full parse on off thread module compilations and this is where the opportunity is, specifically for these files:

Good find! Aligning eager-parse behavior for standard and module scripts makes sense.

Depends on: 1760334
Severity: -- → S3
Priority: -- → P1
Pushed by dpalmeiro@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0e13b764837f Apply delazify strategy to off thread module compilations r=nbp

https://hg.mozilla.org/mozilla-central/rev/0e13b764837f

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox116: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch

(In reply to Pulsebot from comment #11)

Pushed by dpalmeiro@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0e13b764837f
Apply delazify strategy to off thread module compilations r=nbp

== Change summary for alert #38668 (as of Mon, 12 Jun 2023 12:44:09 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new) Performance Profiles
24% pinterest fcp linux1804-64-shippable-qr cold fission webrender 864.55 -> 659.53 Before/After
23% pinterest FirstVisualChange linux1804-64-shippable-qr cold fission webrender 929.44 -> 719.33 Before/After
17% pinterest FirstVisualChange windows10-64-shippable-qr cold fission webrender 687.05 -> 569.63
17% pinterest fcp windows10-64-shippable-qr cold fission webrender 626.52 -> 519.79
14% pinterest ContentfulSpeedIndex linux1804-64-shippable-qr cold fission webrender 1,356.27 -> 1,164.39 Before/After
... ... ... ... ... ...
4% pinterest loadtime windows10-64-shippable-qr cold fission webrender 1,246.57 -> 1,197.47

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=38668

See Also: → 1865929
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: