MozillaZine

Javascript Performance Thread

Discussion about official Mozilla Firefox builds
Josa
 
Posts: 3727
Joined: July 28th, 2009, 4:52 pm

Post Posted December 24th, 2015, 5:20 am

koboltzz wrote:Sorry to ask, but where do you get your informations from about latest changes (summed up) in nightlys?
From http://statusupdates.dev.mozaws.net/ ?

And another question... they are doing some things to touch recognition code. In latest nightly touch is broken.
The 'dom.w3c_touch_events.enabled=2' do not work anymore. Anyone know what to do, to get touch input back?

I get the changes from http://hg.mozilla.org/mozilla-central/shortlog
Yesterday Greeneyes and me were talking about a change that landed only on the pre-Nightly channel, which is http://hg.mozilla.org/integration/mozil ... d/shortlog

Your question should be posted on the Nightly thread, here is just for JS performance stuff.

Ver Greeneyes
 
Posts: 1028
Joined: June 28th, 2008, 4:57 am

Post Posted December 24th, 2015, 6:14 am

I hang out on the Mozilla IRC (mostly keeping up with #jsapi) and follow some people and components on Bugzilla. I don't use the Nightly topic that much, because it would mostly be covering the same ground for me. Following the status updates website would probably be a nice addition, but I have a hard time keeping up with things that I don't have open all the time (like e-mail / IM).

Edit: Okay, I have it e-mailing me now :) Most projects don't seem to really use it, but I decided to 'join' the jsapi and content teams.

bogas04

User avatar
 
Posts: 977
Joined: May 18th, 2010, 1:14 am

Post Posted December 26th, 2015, 10:23 pm

Very off topic, but I don't know where else to ask.

So I've this web app based on React, and I was using animations (https://github.com/rackt/react-router/t ... animations) for route transitions. I noticed that when a bulky page is to be transitioned into, there's a good lag. I used performance tab in dev tools and it showed non-incremental gc doing stuff during those lags.

Now I want to know what code makes FF use non-incremental GC, and how can I use better code to avoid it.

BTW I'm using e10s
bogas04.github.io
MacBook Air Mid 2013 |@bogas04

Ver Greeneyes
 
Posts: 1028
Joined: June 28th, 2008, 4:57 am

Post Posted December 27th, 2015, 7:02 am

There are a few things that can 'reset' an incremental GC and turn it into a full GC, but the most common causes are 1) the Cycle Collector (which tracks and breaks reference cycles between reference counted C++ DOM objects and garbage collected JS objects) requiring a GC to finish to do its work and 2) Falling too far behind trying to GC incrementally. I'm not sure how those causes necessarily translate into anything actionable - maybe you could check how fast things are being allocated and see if you can spread it out somehow. Feel free to file a bug in the JavaScript: GC component (in the Core product) as well, since experts like :terrence, :jonco and :sfink can probably help out more (and anything that causes large amounts of GC-related lag is probably something they want to know about).

Ver Greeneyes
 
Posts: 1028
Joined: June 28th, 2008, 4:57 am

Post Posted December 29th, 2015, 7:09 am

Bug 1215479 has landed on inbound, enabling W^X (writable or executable, but not both) JIT code everywhere! This resulted in a slight regression on SunSpider (180 -> 184 ms) and an even smaller regression on Octane (33350 -> 33100 points), but it is a pretty powerful mitigation technique to protect against security exploits.

Edit: Here's Jan's blog post about this.

KilliK

User avatar
 
Posts: 609
Joined: June 18th, 2004, 7:11 am

Post Posted December 31st, 2015, 6:48 am

excellent. the work the devs are doing in the JSE all these years, is simply astounding.

Ver Greeneyes
 
Posts: 1028
Joined: June 28th, 2008, 4:57 am

Post Posted January 1st, 2016, 5:59 pm

Bug 1120016 just landed on m-c, allowing short-lived JS wrappers to be allocated in the garbage collector's "nursery", a special zone for short-lived allocations that enables very fast (bump) allocation and can be collected very quickly. These wrappers aren't strictly part of the JS engine, but they are created for things like (mouse, keyboard, etc) events on the web, so it's definitely relevant to performance. In addition to allowing for faster allocation of these objects, this might reduce the need for major (slow) GCs, since most of these objects are expected to be dead by the time the nursery is collected.

Edit: Should be in today's Nightly. No idea if it'll be noticeable though :D

Ver Greeneyes
 
Posts: 1028
Joined: June 28th, 2008, 4:57 am

Post Posted January 14th, 2016, 8:31 am

Some interesting developments recently. Firstly, the long-awaited landing of Till Schneidereit's work on self-hosting bound functions in bug 1000780, greatly speeding up bound functions in common cases (while regressing uncommon ones somewhat). Moving the implementation into JS is sort of the opposite approach to what Chrome did - their implementation was already mostly C++, and they moved it to C++ completely. The new JS implementation in Firefox is much faster on some benchmarks, including one developed for the new Chrome implementation.

Second, Yury Delendik has been busy making parsing incremental, and enabled asynchronous script compilation in what sounds like an important case: bug 1236104. 50-80ms main thread jank is not an insignificant amount! I assume pre-loading needs to be active for this to make a difference (e.g. uBlock Origin can turn that off for privacy).

I've also been hearing things about a JITv2 presentation coming up. I'm not sure what that's about - perhaps just a summary of all the enhancements that have been made to IonMonkey and the Baseline Compiler since their inception, or perhaps something new. I believe Hannes Verschore is close to enabling re-use of baseline caches in Ion (bug 1161516), and work on the new WebAssembly compiler (BaldrMonkey) is well underway (bug 1234985).

But most of the work going on right now seems to be about standards compliance and code cleanup. Jan de Mooij recently started working on simplifying how eval frames work in bug 1234845, which should hopefully reduce the amount of confusing code surrounding eval. Shu-yu Guo recently removed the old non-standard array/generator comprehensions in bug 1220564, which broke some extensions but removed some of the scariest code in SpiderMonkey's front-end.

Jeff Walden has been working on parsing of for-in and for-of loops involving let, another scary and not particularly standards compliant part of SM's front-end. That's spread out across a small constellation of bugs, but should land soon. Terrence Cole continues to work on making the Garbage Collector less insane (with help from Steve Fink, and Jon Coppeard for reviews), replacing old dodgy APIs with new, strongly typed ones that don't allow you to shoot yourself in the foot as easily.

I like to point out code cleanup work in this thread, because the easier code is to understand, the easier it is to optimize further. The SM devs have had to cope with a quickly evolving language and trying to keep up with Google's resources, and this has caused a lot of overly complicated code to accrue throughout the codebase. We're now at a point where performance on the important benchmarks is good, so a lot of long-overdue cleanup work is being done. It feels like that work is never done, but if you compare the quality of the code now to where it was a few years ago, they've definitely made big strides - and we've already seen this pay off, with optimizations that would have been too hard to get right before all the refactoring.
Last edited by Ver Greeneyes on January 14th, 2016, 11:49 am, edited 1 time in total.

Grantius

User avatar
 
Posts: 1544
Joined: June 28th, 2011, 4:14 pm

Post Posted January 14th, 2016, 8:51 am

Thanks for the updates, it's really helpful!
Micro gaming box: AMD A10-7800 APU, 8gb RAM M350 ITX case (size of a book), Windows 10/Ubuntu
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86
Mobile:Xiaomi Redmi Note 3 Pro

6lobe
 
Posts: 124
Joined: September 16th, 2014, 8:27 am

Post Posted January 14th, 2016, 9:02 am

Yeah, thanks for keeping us posted. Interesting stuff as always!

Peja Stija

User avatar
 
Posts: 644
Joined: June 4th, 2008, 8:46 am
Location: Belgium (proud producer of waffles)

Post Posted January 14th, 2016, 9:57 am

For the last days everything indeed feels a lot snappier, if only the horribly buggy html5 implementation could be looked into, the future looks bright.

Ver Greeneyes
 
Posts: 1028
Joined: June 28th, 2008, 4:57 am

Post Posted January 14th, 2016, 11:49 am

No problem! I kind of enjoy doing these updates to be honest :)

Omega X

User avatar
 
Posts: 8113
Joined: October 18th, 2007, 2:38 pm
Location: A Parallel Dimension...

Post Posted January 14th, 2016, 3:42 pm

I swear, this is the only moz team I've noticed that get things done quickly, consistently and without the drama.
Latest: Firefox/66.0 *ESR/60.6.0 - Mobile/66.0 - Thunderbird/60.6.0
Nightly: Nightly/68.0a1 - Mobile/68.0a1 - Daily/68.0a1

mayankleoboy1
 
Posts: 454
Joined: February 25th, 2013, 9:52 pm

Post Posted January 14th, 2016, 9:28 pm

Omega X wrote:I swear, this is the only moz team I've noticed that get things done quickly, consistently and without the drama.

GFX team on the other hand....

eltomito
 
Posts: 8
Joined: December 8th, 2013, 5:52 pm

Post Posted January 15th, 2016, 8:02 am

Microsoft seems to have open sourced at least some of its JavaScript engine - http://phoronix.com/scan.php?page=news_ ... ode-Is-Out
Is it enough to put it on AWFY? We could watch the Monkey whooping Microsoft's ass in near real time! :D

Return to Firefox Builds


Who is online

Users browsing this forum: Mark12547, SLK350 and 6 guests