Open Bug 847847 Opened 12 years ago Updated 1 year ago

Moshpit JS simulation is much slower on Firefox than Chrome

Categories

(Core :: JavaScript Engine, defect, P3)

Unspecified
All
defect

Tracking

()

Tracking Status
firefox22 --- affected
firefox130 --- affected

People

(Reporter: cpeterson, Unassigned)

References

(Blocks 1 open bug, )

Details

The moshpit simulation at https://mattbierbaum.github.io/moshpits.js/ is much slower in Firefox than Chrome. I'm testing Nightly 22 on OSX.
Keywords: qawanted
Whiteboard: [needs profiling]
Here is a profile I sampled with a new Firefox user profile. http://people.mozilla.com/~bgirard/cleopatra/#report=f1034b36984021d38bb2c0791020c087c2c0287c Here is a profile I sampled from my default profile: http://people.mozilla.com/~bgirard/cleopatra/#report=4db9b5b1148bb44afbfe20ebfa2aef29409f1521 Surprisingly, the two profiles look pretty different, even if I disable all the add-ons in my default profile. The fresh profile's hotspots are in JS name lookups, but my default profile's hotspots are in canvas drawing.
It's probably worth cloning this report to handle each case.
Keywords: qawanted
Whiteboard: [needs profiling]
Well over half the time here is under js::ion::GetElementIC::update for me, at least if I crank up the number of objects to 5000 or so.... Are we ending up doing the IC thing on an array or typed array or something?
Severity: normal → S3

The default number of balls (500) is fast on latest Nightly. However, if you increase the number of balls to 10x (5000), there is a huge difference.

Nightly: https://share.firefox.dev/3W1Z7ZI (5000 balls)
Chrome: https://share.firefox.dev/3zMxGvt (5000 balls)
Visually, we are a lot slower.

OS: macOS → All
Hardware: x86 → Unspecified

I hacked out the core loop of this code and put it in a shell microbenchmark, then poked at some samply profiles. For reasons I haven't been able to work out, I see a lot of samples locally in mod_rvec, but none in the browser version. I see a big win in my cut-down version by bumping the maximum size of an inlined function up somewhat to inline mod_rvec into update. (Our current max is 130 bytes of bytecode; mod_rvec is 209.) However, it's not clear that will help anything here. I tried a build of Firefox with a higher limit, and couldn't make out any difference in the profiles.

Blocks: sm-js-perf
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.