Javascript Performance Thread
-
- Posts: 269
- Joined: February 7th, 2013, 3:19 pm
Re: Javascript Performance Thread
AWFY added a comparison between OSes: http://arewefastyet.com/#machine=31
- Grantius
- Posts: 1545
- Joined: June 28th, 2011, 4:14 pm
- Contact:
Re: Javascript Performance Thread
Timvde wrote:AWFY added a comparison between OSes: http://arewefastyet.com/#machine=31
It's funny because I definitely find Linux firefox to be hella slower than when I use Windows, even with HWA turned on. It's on a much more powerful machine too
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: 8
- Joined: December 8th, 2013, 5:52 pm
Re: Javascript Performance Thread
Grantius wrote:Timvde wrote:AWFY added a comparison between OSes: http://arewefastyet.com/#machine=31
It's funny because I definitely find Linux firefox to be hella slower than when I use Windows, even with HWA turned on. It's on a much more powerful machine too
I think AWFY is only testing the javascript engine, not the whole of firefox, so it could be the rest of firefox, probrably the UI, that's making it slow. Or it could be that you're using the fglrx AMD graphics driver on Linux which I find buggy in all kinds of weird ways. Try turning HWA off or switching to the on-board graphics, if you have any.
-
- Posts: 269
- Joined: February 7th, 2013, 3:19 pm
Re: Javascript Performance Thread
That's weird. I always have the feeling that Firefox on Linux runs so much better than on Windows (except on heavy graphics stuff). I guess it's hardware-specific.
- Grantius
- Posts: 1545
- Joined: June 28th, 2011, 4:14 pm
- Contact:
Re: Javascript Performance Thread
https://bugzilla.mozilla.org/show_bug.cgi?id=1186409 - Use a single global for all JSMs
Saves about 20MB RAM in the parent Firefox process.
Saves about 20MB RAM in the parent Firefox process.
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: 471
- Joined: February 25th, 2013, 9:52 pm
Re: Javascript Performance Thread
https://bugzilla.mozilla.org/show_bug.cgi?id=1084009 has landed.
No discernible effect on Octane.
No discernible effect on Octane.
-
- Posts: 269
- Joined: February 7th, 2013, 3:19 pm
Re: Javascript Performance Thread
It's been silent in JS land lately... Does anyone have an update about current projects? Or are they mostly busy with implementing ES6?
-
- Posts: 471
- Joined: February 25th, 2013, 9:52 pm
Re: Javascript Performance Thread
1. https://bugzilla.mozilla.org/show_bug.cgi?id=1209515
2.https://bugzilla.mozilla.org/show_bug.cgi?id=1214508
3.https://bugzilla.mozilla.org/show_bug.cgi?id=1207696
4.https://bugzilla.mozilla.org/show_bug.cgi?id=1214126
5.https://bugzilla.mozilla.org/show_bug.cgi?id=1181612
Maybe this too: https://bugzilla.mozilla.org/show_bug.cgi?id=1214961
nothing too big, AFAIK.
2.https://bugzilla.mozilla.org/show_bug.cgi?id=1214508
3.https://bugzilla.mozilla.org/show_bug.cgi?id=1207696
4.https://bugzilla.mozilla.org/show_bug.cgi?id=1214126
5.https://bugzilla.mozilla.org/show_bug.cgi?id=1181612
Maybe this too: https://bugzilla.mozilla.org/show_bug.cgi?id=1214961
nothing too big, AFAIK.
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
I don't think there are any huge projects at the moment, but there are a few interesting ones:
In bug 1214116, jandem is tracking work to refactor ICs for getting/setting properties and elements (I forget what IC stands for - inlined call perhaps). He's already unified the getprop and getelem paths, bringing the getelem paths up to speed. His work on the setprop and setelem paths show similar gains. This work should also make it possible/easier to fix IM's performance on megamorphic getprop/setprop callsites (a longstanding weakness).
In bug 1209515, nbp is working on having IonMonkey remove unused branches with the help of dynamic code coverage tracking. His latest Octane results look very promising, with no big regressions and some large gains (10.2% on Mandreel, 7.3% on Richards and 4.6% on Typescript)!
Additionally, h4writer continues to plug away at sharing baseline caches with IM. I think this has some overlap with the work that jandem is doing, though I'm not sure how much. I'm not sure how far along this project is, though the partial implementation can already be enabled for fuzzing purposes.
Finally, bbouvier is still working toward an ASMJS baseline compiler (but I'm not sure how far along that is), and terrence keeps plugging away at making the GC less convoluted and more efficient. sfink has been working on GC performance as well, mostly related to his work on linear-time WeakMap marking.
bhackett is taking a break from working on JS performance to work on a web replay prototype, jonco (who built the compacting GC) is working on ES6 Modules, and I'm not sure what djvj has been working on. I think that's about it for the usual performance and GC suspects
Edit: Heh, I worked on my post too long. Lot of overlap between what I said and the bugs mayankleoboy1 posted
In bug 1214116, jandem is tracking work to refactor ICs for getting/setting properties and elements (I forget what IC stands for - inlined call perhaps). He's already unified the getprop and getelem paths, bringing the getelem paths up to speed. His work on the setprop and setelem paths show similar gains. This work should also make it possible/easier to fix IM's performance on megamorphic getprop/setprop callsites (a longstanding weakness).
In bug 1209515, nbp is working on having IonMonkey remove unused branches with the help of dynamic code coverage tracking. His latest Octane results look very promising, with no big regressions and some large gains (10.2% on Mandreel, 7.3% on Richards and 4.6% on Typescript)!
Additionally, h4writer continues to plug away at sharing baseline caches with IM. I think this has some overlap with the work that jandem is doing, though I'm not sure how much. I'm not sure how far along this project is, though the partial implementation can already be enabled for fuzzing purposes.
Finally, bbouvier is still working toward an ASMJS baseline compiler (but I'm not sure how far along that is), and terrence keeps plugging away at making the GC less convoluted and more efficient. sfink has been working on GC performance as well, mostly related to his work on linear-time WeakMap marking.
bhackett is taking a break from working on JS performance to work on a web replay prototype, jonco (who built the compacting GC) is working on ES6 Modules, and I'm not sure what djvj has been working on. I think that's about it for the usual performance and GC suspects
Edit: Heh, I worked on my post too long. Lot of overlap between what I said and the bugs mayankleoboy1 posted
-
- Posts: 269
- Joined: February 7th, 2013, 3:19 pm
Re: Javascript Performance Thread
Ver Greeneyes wrote:(I forget what IC stands for - inlined call perhaps)
Inline caches, iirc.
Thanks for the updates, you both, it was very interesting reading these bugs
-
- Posts: 471
- Joined: February 25th, 2013, 9:52 pm
Re: Javascript Performance Thread
https://bugzilla.mozilla.org/show_bug.cgi?id=1209515 is getting some serious action.
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
I posted this in the Nightly thread, but re-posting it here because I think it's relevant to performance (at least smoothness):
"I think today's (2015-11-01) Nightly will have bug 1214961 in it, which might make it significantly less janky in larger sessions. It changes part of the GC that used to be done in full on every slice to instead be done incrementally when it's needed - so that it won't keep blowing out the slice budget and keeping GC from making progress. This is thought to be the main cause of incremental GCs that janked up the browser and took forever to finish."
"I think today's (2015-11-01) Nightly will have bug 1214961 in it, which might make it significantly less janky in larger sessions. It changes part of the GC that used to be done in full on every slice to instead be done incrementally when it's needed - so that it won't keep blowing out the slice budget and keeping GC from making progress. This is thought to be the main cause of incremental GCs that janked up the browser and took forever to finish."
-
- Posts: 7364
- Joined: July 28th, 2009, 4:52 pm
Re: Javascript Performance Thread
Microsoft Edge is now being tested on AWFY: https://arewefastyet.com/#machine=31
- patrickjdempsey
- Posts: 23686
- Joined: October 23rd, 2008, 11:43 am
- Location: Asheville NC
- Contact:
Re: Javascript Performance Thread
I wonder why it's the same color as Safari... they run out of colors after 4 or something?
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
- Omega X
- Posts: 8225
- Joined: October 18th, 2007, 2:38 pm
- Location: A Parallel Dimension...
Re: Javascript Performance Thread
Should have known that OSX Firefox would be faster. Everything they do is OSX first.