Open Bug 1805709 Opened 2 years ago Updated 27 days ago

Codepen demo (https://codepen.io/Bupeldox/pen/oNyrrPw) is slower in 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)

Go to https://codepen.io/Bupeldox/pen/oNyrrPw

https://share.firefox.dev/3FrORBJ

We should be as fast as the competition, if possible.

Attached file Shell testcase
The hotspot here is this function, with 20% of the samples:
```
  forEachNeighbour(f) {
    for (var nx = 0; nx < this.neighbours.length; nx++) {
      if (this.neighbours[nx] !== undefined) {
        for (var ny = 0; ny < this.neighbours[nx].length; ny++) {
          if (this.neighbours[nx][ny] !== undefined) {
            f(this.neighbours[nx][ny], nx - 1, ny - 1);
          }
        }
      }
    }
  }
```
This doesn't seem like it should be that slow.

It was relatively easy to pull out the code and shim the graphics code to run in the shell. Things I noticed: 

1. We don't inline `forEachNeighbour` because it's slightly too big. We don't inline `f` into `forEachNeighbour` because it's polymorphic. This might be a case where our idea of inlining more aggressively if the candidate has polymorphic ICs would help.
2. We're doing `GuardNoDenseElements` on Array.prototype and Object.prototype in the inner loop. Fuses might help here.
Blocks: sm-jits
Severity: -- → N/A
Priority: -- → P3

The demo is still slower than Chrome, but the profile seems to be somewhat different : https://share.firefox.dev/3YqGRbz

Profile with latest Nightly: https://share.firefox.dev/3y4pWnH

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

Attachment

General

Created:
Updated:
Size: