Closed Bug 1852233 Opened 1 years ago Closed 1 years ago

A JS utility takes 2x more time than Chrome and we spend a lot of time around GC. All the rest is spent in Baseline.

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

RESOLVED FIXED

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

Go to http://xem.github.io/hex/viewer_input_es6.html
Choose any local file (atleast 1 MB in size) from your machine

Chrome: https://share.firefox.dev/45JMiH8 (8 seconds)
Nightly: https://share.firefox.dev/3sNQpDB (18 seconds)

If you take a larger (15MB-ish) file, the profile looks like this:

Nightly: https://share.firefox.dev/44DA1Tm (2 minutes)
Chrome: https://share.firefox.dev/3PqY43v (35 seconds)

So looks like as the file size increases, we spend increasingly more time around GC, while the main js part takes roughly the same time in both chrome and nightly.

Summary: A JS utility takes 2x more time than Chrome and we spend all the time in Baseline and around GC → A JS utility takes 2x more time than Chrome and we spend a lot of time around GC (and some time in Baseline due to eval)
Summary: A JS utility takes 2x more time than Chrome and we spend a lot of time around GC (and some time in Baseline due to eval) → A JS utility takes 2x more time than Chrome and we spend a lot of time around GC. All the rest is spent in Baseline.
Severity: -- → N/A
Priority: -- → P3

I tried a autoland build, and the GC part is completely gone from the profile!

profile: https://share.firefox.dev/3Rvrxe3

The gc part is completely fixed.

Is there any interest in investigating/fixing the remaining JS part where all the time is spent in Baseline?

(In reply to Mayank Bansal from comment #4)

Is there any interest in investigating/fixing the remaining JS part where all the time is spent in Baseline?

We spend most of the time doing name lookups (BindName, GetName) in Baseline because the script has a with statement:

h = '<pre>';
with(new FileReader) readAsArrayBuffer(files[0]), onload = s => {
    for (i in u = new Uint8Array(result)) h += (i % 16 ? ' ' : '\n' + (1e7 + (+i)[t = 'toString'](16)).slice(-8) + ' | ') + (0 + u[i][t](16)).slice(-2);
    outerHTML = h
}

This is really poorly written JS code.

We don't Warp compile the onload arrow function because Warp doesn't support JSOp::GetBoundName yet. That's fixable, but it's also low priority and this website would still be pretty slow due to the slow name lookups.

Sounds like the remaining parts are a known thing (and probably tracked elsewhere), and we are comparable to Chrome now. The GC issue has been fixed.
I will close this bug. Thanks!

Status: NEW → RESOLVED
Closed: 1 years ago
Resolution: --- → FIXED

FWIW, the profile in latest Nightly : https://share.firefox.dev/3BOQn37
All the time is in ion now.
I will give credit to bug 1916185

Depends on: 1916185
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: