Open Bug 1910925 Opened 11 months ago Updated 4 months ago

Modified Codepen demo (https://codepen.io/MittenedWatchmaker/pen/mzGdLM) gets relatively slower on Nightly compared to Chrome

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 2 open bugs, )

Details

Attachments

(1 file)

Open the modified Codepen demo

Nightly: https://share.firefox.dev/3LRugu8 (19s)
Chrome: https://share.firefox.dev/4fpSeug (11s)

As you keep on increasing the size of the "init" in the js, the difference between Nightly and Chrome widens.

Summary: Modified Codepen demo (https://codepen.io/MittenedWatchmaker/pen/mzGdLM) takes more time to run on Nightly → Modified Codepen demo (https://codepen.io/MittenedWatchmaker/pen/mzGdLM) gets relatively slower on Nightly compared to Chrome

This is all in Ion JIT code. Likely some guards we fail to optimize or something similar.

Taking a quick look at a profile and the iongraph, this might have something to do with V8's optimization to have special representation for integer arrays. The hot loop is this code:

while(directions[x][y]!=5) {
  //console.log(x,y,directions[x][y])
  x-=(directions[x][y]==1)-(directions[x][y]==2);
  y-=(directions[x][y]==3)-(directions[x][y]==4);
  if(flux[x][y]==0){fluxval++}
  flux[x][y]+=fluxval;
}

And it looks from the profile like we spend a significant fraction of our time unboxing the contents of `directions.

I'm not sure we have an easy way to speed this up.

Blocks: sm-opt-jits
Severity: -- → N/A
Priority: -- → P3

I took another quick look at this to see whether GVN was failing to common up all the loads of directions[x][y], but that turns out not to be the case. We load it once at the top of the loop, and then again after modifying x in the x-= line. So GVN is working as expected here.

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

Attachment

General

Creator:
Created:
Updated:
Size: