Yep, though important to note that (as stated in the bug) this doesn't mean concurrent GC - it just means that the main thread will wait on the GC thread, instead of running GC in the main thread. Still, this is the first step toward concurrent GC, which is an eventual goal

i was just looking at arewefastyet.com , and on the Octane benchmark, JSC and the newer V8 engines are doing very well.Firefox looks slower in comparison.AFAIR, we had reached an almost parity with V8, and JSC was slower than both. What the hell did these guys do, and why isnt IM doing them

The main gap in performance seems to be on 64-bit builds. Bug 1308506 is open about that, but I'm not sure when it'll get the focus. Recently the focus has been on architectural improvements like splitting out control flow graph generation and CacheIR, though I think most of the resources are going into developing the WebAssembly engine BaldrMonkey.

They created a meta bug about performance: https://bugzilla.mozilla.org/show_bug.cgi?id=1307062But I think only Jan de Mooij is focused on improving performance. There's people working on WASM, conformance to ES6 / ES2017, js-startup-cache... Brian Hackett has been working on the Web Replay for a year... I hope that really is worthy.

mayankleoboy1 wrote:https://bugzilla.mozilla.org/show_bug.cgi?id=1324002Brian Hackett started working on JS again \o/

Indeed! Also check out the bug it blocks, bug 1323066, which is potentially very exciting. As you all probably know, Firefox is never going to do Chrome-style process-per-tab. Even Chrome is moving away from that model to improve memory usage last I heard. But right now Javascript for all tabs is run on a single thread!

It looks like we might finally be in a position to change that, now we have a compartment per global, the old ineffable JSContexts have gone away (the one that's left becoming the new JSRuntime), memory allocation happens per zone, and zones roughly (if not completely) correspond to a tab. It'll take some work in the JS engine to try and eliminate full GCs, and some work on the Gecko end to make things thread-safe, but it would be a great boon to responsiveness if they could pull it off.

In recent performance news, check out the dependencies of the CacheIR tracking bug! jandem and evilpie have been plugging away at expanding CacheIR and optimizing more cases. There's a WIP in bug 965992 that fixes a long-standing DOM performance issue using CacheIR, and evilpie is finding interesting things that affect sites like Twitter and Google Docs.

jandem wrote a blog post about the recent CacheIR developments: check it out It's been very satisfying to follow along with this work, watching jandem and evilpie solve years old performance bugs, remove tons of hairy code and discover and fix performance issues on big websites that would have been pretty painful to fix before now. The CacheIR-to-MIR compiler sounds like it should be a nice generalization and make ICs into true first-class citizens as far as code generation is concerned!

Here's a newsgroup post by Brian Hackett about his ongoing work to make the JS engine multi-threaded. This will potentially put each tab on its own thread (execution context, technically, with a thread pool serving each context in a round robin fashion), which should be a great boon to performance for anyone with more tabs than processes! The work is still in its early stages, but there don't seem to be any huge roadblocks anymore

Why isn't there any progress on any Benchmark on the front page of AWFY in the last month?I know Sunspider isn't that representative any more but why its staying at the front page?Are there any better "modern" Benchmarks that show more the improvements in the JS Engine?