MozillaZine

Javascript Performance Thread

Discussion about official Mozilla Firefox builds
Dingler

User avatar
 
Posts: 1243
Joined: November 14th, 2011, 4:41 am

Post Posted May 13th, 2016, 4:44 am

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: 970
Joined: June 28th, 2008, 4:57 am

Post Posted May 13th, 2016, 8:01 am

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

Josa
 
Posts: 2147
Joined: July 28th, 2009, 4:52 pm

Post Posted June 28th, 2016, 10:19 am

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

Josa
 
Posts: 2147
Joined: July 28th, 2009, 4:52 pm

Post Posted July 5th, 2016, 8:42 pm


Grantius

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

Post Posted July 6th, 2016, 12:42 am

Josa wrote: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?
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: 118
Joined: April 30th, 2011, 11:30 pm

Post Posted July 6th, 2016, 3:29 am

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

A new JS engine?


new JIT compiler for SpiderMonkey.

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

Post Posted July 12th, 2016, 5:21 am

Grantius wrote:
Josa wrote: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

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

Post Posted July 12th, 2016, 5:35 am

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

Post Posted July 12th, 2016, 6:00 am

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: 253
Joined: February 7th, 2013, 3:19 pm

Post Posted September 10th, 2016, 10:39 am

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

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

Post Posted October 16th, 2016, 7:16 pm

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: 864
Joined: March 14th, 2010, 3:44 am

Post Posted October 16th, 2016, 7:23 pm

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: 292
Joined: October 14th, 2013, 1:20 pm

Post Posted October 17th, 2016, 11:27 am

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: 970
Joined: June 28th, 2008, 4:57 am

Post Posted October 19th, 2016, 4:04 am

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

User avatar
 
Posts: 869
Joined: March 17th, 2008, 5:32 am
Location: Australia

Post Posted October 19th, 2016, 6:50 am

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

Return to Firefox Builds


Who is online

Users browsing this forum: No registered users and 1 guest