Closed Bug 1798444 Opened 2 years ago Closed 2 years ago

Codepen demo appears to spend a lot of time in Baseline

Categories

(Core :: JavaScript Engine, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

Go to https://codepen.io/iondrimba/pen/qBYeWdX

Profile: https://share.firefox.dev/3UflVCK

Maybe we can do something better here.

Attached file about:support (deleted) —
Flags: needinfo?(jdemooij)

This performs fine for me on Mac. I get about 120 fps. Chrome is fast too but Safari is pretty slow.

About "a lot of time in Baseline", the profile in comment 0 has 81% Ion, 12% Baseline, so it's not too bad.

Flags: needinfo?(jdemooij)

I get only ~10 fps on Linux. However, like the reported profile internalStep is taking most of the time, with half of it in getContacts.
getContacts then goes into an IC and calling js::jit::InvokeFunction with a function.call which result in calling sphereBox.

I wonder if the problem is not the fact that this IC get introduced without a better optimization path. But that would not explain the gap between 10 fps and 120 fps.

When I reduce then number of balls (line 432), I get only 30 fps. In chromium, I get ~20fps when running.

I will note that getContacts ratio does not seems to evolve much with the number of balls simulated.
Also, I wonder if the internalStep function is attempting to have perfect physics by simulating every extra time-steps between refreshAnimationFrames. Thus filling the profile to fit the refresh rate of the display.

In any case, the initial report from being stuck in baseline does not seems to hold.

Severity: -- → S4
Status: NEW → RESOLVED
Type: task → defect
Closed: 2 years ago
Priority: -- → P3
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: