Javascript Performance Thread

[Dingler]

According to a user, bug 1271929 has improved a few tests from Kraken and Sunspider. This patch is a part of JS optimization in bug 1271473.

[Ver Greeneyes]

Cool, I wonder if that means bug 1272598 will help too (since it focuses on optimizing the same microbenchmark).

[Josa]

Branch pruning landed 2 hours ago and seems to have sticked. It's a win in a lot of benchmarks.

[Josa]

https://blog.mozilla.org/javascript/201 ... ur-behalf/

[Grantius]

https://blog.mozilla.org/javascript/2016/07/05/ionmonkey-evil-on-your-behalf/

> in the future in a project with the code name ThreeHeadedMonkey.

A new JS engine?

[mozian]

> in the future in a project with the code name ThreeHeadedMonkey.

A new JS engine?

new JIT compiler for SpiderMonkey.

[Ver Greeneyes]

https://blog.mozilla.org/javascript/2016/07/05/ionmonkey-evil-on-your-behalf/

> in the future in a project with the code name ThreeHeadedMonkey.

A new JS engine?

A project to optimize the compilation speed of IonMonkey to minimize the cost of bailing out. That should allow them to perform more speculative optimizations and/or add additional compilation tiers.

[Grantius]

https://blog.mozilla.org/javascript/2016/07/05/ionmonkey-evil-on-your-behalf/

> in the future in a project with the code name ThreeHeadedMonkey.

A new JS engine?

A project to optimize the compilation speed of IonMonkey to minimize the cost of bailing out. That should allow them to perform more speculative optimizations and/or add additional compilation tiers.

Any of which helps standard web browsing e.g. Facebook etc, or just games/benchmarks?

[Ver Greeneyes]

Any of which helps standard web browsing e.g. Facebook etc, or just games/benchmarks?

It'll help whenever Ion kicks in. Right now that's at 1000 iterations, e.g. functions or loops that have run at least 1000 times, but that limit is based (in part) on compilation overhead. All else being equal, reducing compilation time will help short running code more than long running code, but if they start introducing optimizations that have a higher chance of bailing out (like making the branch pruning more aggressive) both could benefit.

As for how often Ion kicks in during normal browsing, I don't know. I wouldn't be surprised if it kicks in after you interact with a web page for a bit (including things like Facebook or Google Docs), but garbage collection also collects JITcode that isn't in use, so it depends on timing.

[Timvde]

The V8 team is now also building an interpreter as an extra tier to their JS engine: https://v8project.blogspot.be/2016/08/f ... reter.html
There's a line on AWFY

[KilliK]

any news on the project?
Meanwhile, Chrome 55 is going to introduce an improved JSE which cuts the memory consumption to half, according to the devs at least:
http://v8project.blogspot.gr/2016/10/fa ... emory.html

[dbcooper.dk]

any news on the project?
Meanwhile, Chrome 55 is going to introduce an improved JSE which cuts the memory consumption to half, according to the devs at least:
http://v8project.blogspot.gr/2016/10/fa ... emory.html

Update: All the improvements discussed above reduce the Chrome 55 overall memory consumption by up to 35% on low-memory devices compared to Chrome 53. Other device segments will only benefit from the zone memory improvements.

[PadaV4]

Well at least they are doing something. Once Firefox starts to use multiple content processes, they really should do a new Memshrink initiative because its really starting to use massive amount of memory with multiple content processes + 64 bit.

[Ver Greeneyes]

I'm not sure if there's a lot of new stuff to report. On the performance side, a lot of work is going into WebAssembly. That's a big project, and will probably be very important for more heavy duty applications in the future, but it's not going to affect the web in general. Outside of that, a lot of work has gone into stability, and diagnosing performance of Google Docs (progress has been made, but it seems like a difficult nut to crack).

Shu's rewrite of the bindings part of the frontend landed, which turns things like 'let' and 'const' into first class citizens (the old code was a mess and held up a fair bit of standards compliance work). That didn't really affect performance, though it caused a regression with the cycle collector that has since been fixed. Here's a blog post about the new algorithm.

Nicolas just posted patches for caching javascript bytecode, which should help performance across restarts of the browser. Jan landed a patch to compress and decompress script source in chunks, which should help a lot in certain cases, and on the GC side a lot of work has gone into stability regarding interactions between the GC and the cycle collector, which probably fixed several mysterious crashes.

Oh, and regarding Memshrink, Jan landed several improvements for e10s with multiple content processes, most notably bug 1295967 to share 'shapes' across compartments. Bug 1297706 and bug 1303754 should improve both performance and memory usage in e10s by allowing us to syntax parse more scripts (thus preventing the work and allocations associated with full parsing).

Edit: I just thought of another important e10s performance improvement: as of bug 1279086, we now allow painting for tab switch even while running JS code. Obviously that won't make the JS code run any faster, but it should greatly improve perceived responsiveness in certain situations. This has also been extended to work while the GC is running, and a bug is open for the cycle collector.

[squall_leonhart]

i really do wish the change in https://bugzilla.mozilla.org/show_bug.cgi?id=1209689 was selectable by the user and not a hardset change.

i'm stuck on 44 till lazy session restoring is ready