Closed
Bug 914342
Opened 11 years ago
Closed 10 years ago
Firefox 3X slower than Chrome on number game benchmark
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: dvander, Assigned: jandem)
References
()
Details
(Keywords: perf)
Attachments
(1 file)
(deleted),
application/x-javascript
|
Details |
The author of the benchmark sent me an e-mail that it runs significantly slower in Firefox. I tried it on a VM and it does appear to be about 3X slower (tested Nightly vs Canary).
Reporter | ||
Updated•11 years ago
|
Summary: Firefox 4X slower than Chrome on number game benchmark → Firefox 3X slower than Chrome on number game benchmark
Comment 2•11 years ago
|
||
I updated the script so the use of workers is optional. While it gets a bit faster, it's only a tiny bit (it gets a tiny bit faster in Chrome that way, too). I use workers so the output can dynamically update and Firefox won't complain about a slow running script.
Btw.: I could not manage to profile the script using workers. Can Firefox do that or do I miss something? I couldn't find such an option in Chrome either.
Comment 3•11 years ago
|
||
panzi, thank you.
Looks like the time is in fact mostly in jitcode. There's a bit of DoUseCountFallback, and js::jit::Compile in the profile.
JIT inspector claims some hot GetPropertyPolymorphicT in function solutions(), but not sure where since it no longer matches up hot blocks to code lines. :(
Assignee | ||
Comment 4•11 years ago
|
||
panzi: cool website! A long time ago I wrote something similar in Python for a school project. The goal was for very positive integer <= 100 (I think) to find an expression that results in that number, using only the first 5 primes (and we had to use all numbers exactly once) ;)
Looking into this now.
Assignee: general → jdemooij
Assignee | ||
Comment 5•11 years ago
|
||
I converted this to a shell testcase and get these numbers:
SM : 3.2 seconds
d8 : 2.9 seconds
So we're still slower but the difference is *much* smaller. For Chrome, there's no difference between the browser and shell.
Either it improved a lot very recently or it's slower in the browser for some reason.
Assignee | ||
Comment 6•11 years ago
|
||
After updating my nightly, it runs in 3.44 seconds (without workers) or 4.11 seconds (with workers). So it does look like something made this a lot faster. Will see if I can find out what exactly.
Assignee | ||
Comment 7•11 years ago
|
||
Without parallel compilation, this is the range where it got faster in the shell:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=77ed46bf4c1a&tochange=ab5f29823236
What's weird though is that with --ion-parallel-compile=on it's fast with all shell builds I tried. That doesn't match what we see in the browser..
Assignee | ||
Comment 8•11 years ago
|
||
I downloaded some inbound builds and it looks like bug 897926 made this fast in the shell without parallel compilation. Looking at the "solutions" function, that seems reasonable.
Still not sure why it didn't affect parallel compilation runs in the shell (but did affect the browser which has parallel compilation enabled).
Depends on: 897926
Flags: needinfo?(jdemooij)
Assignee | ||
Comment 9•11 years ago
|
||
I get 3.15 seconds with a GGC build, still about 300 ms slower than V8. We spend almost all time in JIT code though and I don't see anything obvious. We inline a ton of scripts but most of these are very small.
This probably needs a bunch of small optimizations, like inlining more property gets/sets/adds directly without using IC's.
Assignee | ||
Comment 10•10 years ago
|
||
We're now a bit faster than Chrome:
Workers:
Nightly: 2.122 seconds
Chrome 39 dev: 2.513 seconds
Without workers:
Nightly: 2.166 seconds
Chrome 39 dev: 2.333 seconds
You need to log in
before you can comment on or make changes to this bug.
Description
•