Javascript Performance Thread

Discussion about official Mozilla Firefox builds
Post Reply
User avatar
Dingler
Posts: 1245
Joined: November 14th, 2011, 4:41 am

Re: Javascript Performance Thread

Post by 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
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

Cool, I wonder if that means bug 1272598 will help too (since it focuses on optimizing the same microbenchmark).
Josa
Posts: 7360
Joined: July 28th, 2009, 4:52 pm

Re: Javascript Performance Thread

Post by Josa »

Branch pruning landed 2 hours ago and seems to have sticked. It's a win in a lot of benchmarks.
Josa
Posts: 7360
Joined: July 28th, 2009, 4:52 pm

Re: Javascript Performance Thread

Post by Josa »

User avatar
Grantius
Posts: 1545
Joined: June 28th, 2011, 4:14 pm
Contact:

Re: Javascript Performance Thread

Post by Grantius »

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

A new JS engine?
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
mozian
Posts: 156
Joined: April 30th, 2011, 11:30 pm
Location: HK

Re: Javascript Performance Thread

Post by mozian »

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

A new JS engine?
new JIT compiler for SpiderMonkey.
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

Grantius wrote:
> 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.
User avatar
Grantius
Posts: 1545
Joined: June 28th, 2011, 4:14 pm
Contact:

Re: Javascript Performance Thread

Post by Grantius »

Ver Greeneyes wrote:
Grantius wrote:
> 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?
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
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

Grantius wrote: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
Posts: 269
Joined: February 7th, 2013, 3:19 pm

Re: Javascript Performance Thread

Post by 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 :)
User avatar
KilliK
Posts: 612
Joined: June 18th, 2004, 7:11 am

Re: Javascript Performance Thread

Post by 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
Posts: 895
Joined: March 14th, 2010, 3:44 am

Re: Javascript Performance Thread

Post by dbcooper.dk »

KilliK wrote: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
Posts: 308
Joined: October 14th, 2013, 1:20 pm

Re: Javascript Performance Thread

Post by 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
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by 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.
User avatar
squall_leonhart
Posts: 885
Joined: March 17th, 2008, 5:32 am
Location: Australia
Contact:

Re: Javascript Performance Thread

Post by 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
Post Reply