Javascript Performance Thread

Discussion about official Mozilla Firefox builds
Post Reply
dbcooper.dk
Posts: 895
Joined: March 14th, 2010, 3:44 am

Re: Javascript Performance Thread

Post by dbcooper.dk »

Josa wrote:GGC will end with JS fragmentation, which I think it's gonna be the last big gain in memory usage. Checking my about:memory, js-main-runtime-gc-heap-committed unused is always between 40% and 60%. From 20MB to 50MB on a regular session.


Lazy bytecode generation is still to come too.

https://bugzilla.mozilla.org/show_bug.cgi?id=678037
phuzi0n
Posts: 517
Joined: June 23rd, 2010, 5:48 pm

Re: Javascript Performance Thread

Post by phuzi0n »

iwod wrote:
Grantius wrote:
iwod wrote:Does anyone know why removing the decompiler would actually causes an increase in code and file size?


What did you get this from?


https://bugzilla.mozilla.org/show_bug.cgi?id=718969

Care to be more specific? That patch removes 184KB of code and only adds 8 lines.
User avatar
Pravda
Posts: 280
Joined: February 16th, 2012, 5:09 pm

Re: Javascript Performance Thread

Post by Pravda »

Josa wrote:which I think it's gonna be the last big gain in memory usage.


There are still a lot of outstanding bugs regarding efficient image decoding and discarding which might also severely lower memory consumption on websites with many images.
You can't handle the правда!
dbcooper.dk
Posts: 895
Joined: March 14th, 2010, 3:44 am

Re: Javascript Performance Thread

Post by dbcooper.dk »

The compartment per global overhead is still to be "clawed back" too.
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

Yeah, I was more referring to effects of JS memory usage on performance by causing untimely GC. In terms of sheer usage there's definitely more that can be done, though how much remains to be seen.
h4writer
Posts: 23
Joined: September 13th, 2011, 4:25 pm

Re: Javascript Performance Thread

Post by h4writer »

A small update for you guys on the different compilers and GGC. I hope it answers some questions you had.

1) What's the deal with GGC and the impact for performance
I'm not involved with GGC and I only hear bits and pieces about it. But from what I've heard the GGC development is going nicely. There is still a lot of work to do, but it is coming. It will probably take another 2-3 months to get it in a functional state. It will decrease the GC pauzes even more and that will be very noticeable in the browser. As for increasing performance, yes it will increase performance, but only by reducing the GC time that happens during benchmarks. That means no increase for SS. For V8 we already identified some places that will definitely benefit from it. BUT the performance atm is not blocked on GGC. For most benchmarks where we are not on par with google chrome, the improvements coming from IonMonkey will be greater than the improvements GGC will bring. (At least that's what I assume from the measurements I did)

2) What's the deal with JaegerMonkey
It will get removed :D. Yeah I'm really happy with that. There are some reasons for this. Many optimizations in JaegerMonkey are hacked together, because there is no decent way to do. IonMonkey has a much easier/better design in that regard. Also JaegerMonkey needs to recompile whenever types changes ... That's one of the reasons of our bad performance on SS. Also it looses it's information when we compile IonMonkey, resulting in the performance differences of 10% on some V8 benchmarks. ETA is when the replacement baseline compiler is done and at least as fast as JaegerMonkey.

3) What's the deal with Baseline
Shaping up nicely. The basic design is done and the hardest part are in. That is almost all opcodes get compiled to a basic version. Later on we can improve the generated output by seeing which types flow in. Evilpie, a contributor, has already begon with this, Thanks! But the major focus is nowto fix all the failing tests. Last thing I heard it would take another 2-3 months.

4) What's the deal with IonMonkey
Most faults are now gone and we are fully looking at performance issues. Mostly on the V8 benchmark, a benchmark where we were historically bad at. That has given us already nice gains since October. This focus will continue in the next few months.
irc nick: h4writer #ionmonkey / #jsapi, https://twitter.com/h4writer
Josa
Posts: 7404
Joined: July 28th, 2009, 4:52 pm

Re: Javascript Performance Thread

Post by Josa »

From https://wiki.mozilla.org/Platform/2013-02-05

ASM.js
BananaBread has been successfully ported using ASM.js.
Current speed ups are about x4 faster than the JS equivalent.
Although there are plenty of optimizations still left to do, we are moving to land the code.
The current estimation is about a month of work left prior to seeing it land supporting mobile and desktop.
User avatar
Grantius
Posts: 1545
Joined: June 28th, 2011, 4:14 pm
Contact:

Re: Javascript Performance Thread

Post by Grantius »

haytjes wrote:A small update for you guys on the different compilers and GGC. I hope it answers some questions you had.

1) What's the deal with GGC and the impact for performance
I'm not involved with GGC and I only hear bits and pieces about it. But from what I've heard the GGC development is going nicely. There is still a lot of work to do, but it is coming. It will probably take another 2-3 months to get it in a functional state. It will decrease the GC pauzes even more and that will be very noticeable in the browser. As for increasing performance, yes it will increase performance, but only by reducing the GC time that happens during benchmarks. That means no increase for SS. For V8 we already identified some places that will definitely benefit from it. BUT the performance atm is not blocked on GGC. For most benchmarks where we are not on par with google chrome, the improvements coming from IonMonkey will be greater than the improvements GGC will bring. (At least that's what I assume from the measurements I did)

2) What's the deal with JaegerMonkey
It will get removed :D. Yeah I'm really happy with that. There are some reasons for this. Many optimizations in JaegerMonkey are hacked together, because there is no decent way to do. IonMonkey has a much easier/better design in that regard. Also JaegerMonkey needs to recompile whenever types changes ... That's one of the reasons of our bad performance on SS. Also it looses it's information when we compile IonMonkey, resulting in the performance differences of 10% on some V8 benchmarks. ETA is when the replacement baseline compiler is done and at least as fast as JaegerMonkey.

3) What's the deal with Baseline
Shaping up nicely. The basic design is done and the hardest part are in. That is almost all opcodes get compiled to a basic version. Later on we can improve the generated output by seeing which types flow in. Evilpie, a contributor, has already begon with this, Thanks! But the major focus is nowto fix all the failing tests. Last thing I heard it would take another 2-3 months.

4) What's the deal with IonMonkey
Most faults are now gone and we are fully looking at performance issues. Mostly on the V8 benchmark, a benchmark where we were historically bad at. That has given us already nice gains since October. This focus will continue in the next few months.


So these improvements, do they help the general browsing experience or is it just for benchmarks?
Last edited by Grantius on February 6th, 2013, 1:25 pm, edited 1 time in total.
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
greg86
Posts: 50
Joined: January 28th, 2007, 11:33 am
Location: Germany
Contact:

Re: Javascript Performance Thread

Post by greg86 »

Graphs on all Machines are broken..

haytjes wrote:...
2) What's the deal with JaegerMonkey
...
That's one of the reasons of our bad performance on SS
...

But why was JM + TI (state of ~ Aug 2012) still faster at SS then Ion?
Because of lots of regressions it is now ~ 30ms slower..

And where can i see the full graph from the begin of the performance records to now?
User avatar
ferongr
Posts: 537
Joined: February 16th, 2011, 9:51 am

Re: Javascript Performance Thread

Post by ferongr »

Sunspider sucks and is not really indicative of the requirements of modern webapps.
What Falken giveth, the tōge taketh away.
dbcooper.dk
Posts: 895
Joined: March 14th, 2010, 3:44 am

Re: Javascript Performance Thread

Post by dbcooper.dk »

Thanks for the great post haytjes.

I have a question about a regexp perf issue that hangs my browser on blogspot sites. Is there any chance the bug will be fixed?

https://bugzilla.mozilla.org/show_bug.cgi?id=792797
User avatar
Zlip792
Posts: 1340
Joined: May 7th, 2011, 1:47 pm
Location: Pakistan

Re: Javascript Performance Thread

Post by Zlip792 »

dbcooper.dk wrote:Thanks for the great post haytjes.

I have a question about a regexp perf issue that hangs my browser on blogspot sites. Is there any chance the bug will be fixed?

https://bugzilla.mozilla.org/show_bug.cgi?id=792797


It can be related in some way to this as well: https://bugzilla.mozilla.org/show_bug.cgi?id=837845
Srap
Posts: 290
Joined: July 18th, 2012, 11:57 am

Re: Javascript Performance Thread

Post by Srap »

haytjes wrote:Mostly on the V8 benchmark, a benchmark where we were historically bad at.

Isn't Peacekeeper is where Firefox tends to be actually bad?
Sorry for my bad English. Even if there wasn't a mistake.
phuzi0n
Posts: 517
Joined: June 23rd, 2010, 5:48 pm

Re: Javascript Performance Thread

Post by phuzi0n »

Srap wrote:
haytjes wrote:Mostly on the V8 benchmark, a benchmark where we were historically bad at.

Isn't Peacekeeper is where Firefox tends to be actually bad?

Isn't Peacekeeper is where benchmarks tends to be actually bad?
User avatar
ferongr
Posts: 537
Joined: February 16th, 2011, 9:51 am

Re: Javascript Performance Thread

Post by ferongr »

Srap wrote:
haytjes wrote:Mostly on the V8 benchmark, a benchmark where we were historically bad at.

Isn't Peacekeeper is where Firefox tends to be actually bad?


Well, people don't really care about Peacekeeper and I don't blame them. The original Peacekeeper version didn't even measure things correctly.
What Falken giveth, the tōge taketh away.
Post Reply