Javascript Performance Thread
- Dingler
- Posts: 1245
- Joined: November 14th, 2011, 4:41 am
Re: Javascript Performance Thread
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.
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
Cool, I wonder if that means bug 1272598 will help too (since it focuses on optimizing the same microbenchmark).
-
- Posts: 7408
- Joined: July 28th, 2009, 4:52 pm
Re: Javascript Performance Thread
Branch pruning landed 2 hours ago and seems to have sticked. It's a win in a lot of benchmarks.
-
- Posts: 7408
- Joined: July 28th, 2009, 4:52 pm
- Grantius
- Posts: 1545
- Joined: June 28th, 2011, 4:14 pm
- Contact:
Re: Javascript Performance Thread
> 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
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86
Mobile:Xiaomi Redmi Note 3 Pro
-
- Posts: 156
- Joined: April 30th, 2011, 11:30 pm
- Location: HK
Re: Javascript Performance Thread
new JIT compiler for SpiderMonkey.> in the future in a project with the code name ThreeHeadedMonkey.
A new JS engine?
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
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 wrote:> in the future in a project with the code name ThreeHeadedMonkey.
A new JS engine?
- Grantius
- Posts: 1545
- Joined: June 28th, 2011, 4:14 pm
- Contact:
Re: Javascript Performance Thread
Any of which helps standard web browsing e.g. Facebook etc, or just games/benchmarks?Ver Greeneyes wrote: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 wrote:> 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
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86
Mobile:Xiaomi Redmi Note 3 Pro
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
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.Grantius wrote:Any of which helps standard web browsing e.g. Facebook etc, or just games/benchmarks?
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.
-
- Posts: 269
- Joined: February 7th, 2013, 3:19 pm
Re: Javascript Performance Thread
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
There's a line on AWFY
- KilliK
- Posts: 612
- Joined: June 18th, 2004, 7:11 am
Re: Javascript Performance Thread
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
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
-
- Posts: 895
- Joined: March 14th, 2010, 3:44 am
Re: Javascript Performance Thread
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.
-
- Posts: 308
- Joined: October 14th, 2013, 1:20 pm
Re: Javascript Performance Thread
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.
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
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.
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
- Posts: 885
- Joined: March 17th, 2008, 5:32 am
- Location: Australia
- Contact:
Re: Javascript Performance Thread
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
i'm stuck on 44 till lazy session restoring is ready