Closed Bug 1351102 Opened 8 years ago Closed 8 years ago

Up to 8 times slower JS performance compared to Chrome in attached code

Categories

(Core :: JavaScript Engine: JIT, defect)

50 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox55 --- fixed

People

(Reporter: Boris.Letocha, Assigned: jandem)

References

Details

Attachments

(2 files)

Attached file code.js (deleted) —
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36 Steps to reproduce: Run attached JS code in simple page: <html> <body> <script src="code.js"></script> </body> </html> Actual results: On my Intel notebook Windows Firefox 50.1 displays this in console: Bobx observable get+set 1M: timer started Bobx observable get+set 1M: 213.97ms 1010000 Bobx observable get+set 1M: timer started Bobx observable get+set 1M: 203.21ms 1010000 Expected results: I would like to see much better performace. Same code in latest Chrome 57 it writes to console (run it with closed dev tools): Bobx observable get+set 1M: 39.5ms 1010000 Bobx observable get+set 1M: 25.8ms 1010000 Sorry for still relatively long code to reproduce.
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Flags: needinfo?(jdemooij)
Thanks for filing this bug. (Note that Firefox 50.1 is no longer supported.) I get the following numbers on OS X: Firefox 52.0.1: 120 ms Safari: 54 ms Nightly (55): 45 ms Chrome: 20 ms So our Nightly builds are almost 3x faster than Firefox 52, but still slower than Chrome.
This is really weird. In our JS shell and sometimes in my Nightly build I get numbers like 3-8 ms. I wonder if it's some inlining or GC quirk. Boris, would you mind trying a Nightly build on Windows and measuring with the console closed?
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → JavaScript Engine: JIT
Ever confirmed: true
Hm there seems to be a problem with console.time/timeEnd. If I replace that with: var t = new Date; ... console.log(new Date - t); I consistently get 3-8 ms on Firefox Nightly and Chrome is still at 23 ms with that, so we're way faster. I'll do some more digging.
Attached patch Patch (deleted) — Splinter Review
Tracked it down to the same-compartment check in GetFinishedBuilder. Replacing that with a same-runtime check gives us the 4-5x faster than Chrome numbers all the time. (What was happening is that console.time() (also reproducible with console.log) entered system JS, then we got the interrupt and the finished off-thread compilation got ignored.)
Assignee: nobody → jdemooij
Flags: needinfo?(jdemooij)
Attachment #8851973 - Flags: review?(hv1989)
Comment on attachment 8851973 [details] [diff] [review] Patch Review of attachment 8851973 [details] [diff] [review]: ----------------------------------------------------------------- Good find!
Attachment #8851973 - Flags: review?(hv1989) → review+
I can confirm that in current nightly (55.0a1 2017-03-28) (64bit) I am seeing randomly 65ms or 7ms. So if this patch will make it consitently faster way, it will be tremendous. Now maybe I should report it to V8 guys :-)
Pushed by jandemooij@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/70fcc672ffd5 Fix GetFinishedBuilder to check the runtime instead of the compartment. r=h4writer
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: