Javascript Performance Thread
-
- Posts: 7416
- Joined: July 28th, 2009, 4:52 pm
Re: Javascript Performance Thread
Edge is already present on AWFY: https://arewefastyet.com/#machine=31
- bogas04
- Posts: 977
- Joined: May 18th, 2010, 1:14 am
Re: Javascript Performance Thread
Damn that Sunspider performance, 2-2.3x faster than Chrome/Firefox on Windows 10.Josa wrote:Edge is already present on AWFY: https://arewefastyet.com/#machine=31
-
- Posts: 471
- Joined: February 25th, 2013, 9:52 pm
Re: Javascript Performance Thread
AFAIU, moz devs arent looking to improve sunspider anymore.bogas04 wrote:Damn that Sunspider performance, 2-2.3x faster than Chrome/Firefox on Windows 10.Josa wrote:Edge is already present on AWFY: https://arewefastyet.com/#machine=31
And for octane, we have this: https://bugzilla.mozilla.org/show_bug.cgi?id=1162272
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
Yes. From what I recall, Hannes (maintainer of AWFY) tested it and this test single handedly puts them in the #1 spot on Octane. Which is ironic, because Chrome also does well on it for suspicious reasons - yet they don't benefit nearly as much.mayankleoboy1 wrote:And for octane, we have this: https://bugzilla.mozilla.org/show_bug.cgi?id=1162272
-
- Posts: 471
- Joined: February 25th, 2013, 9:52 pm
Re: Javascript Performance Thread
http://statusupdates.dev.mozaws.net/use ... ozilla.comThe new & official code name for JIT-v2 is ThreeHeadedMonkey.
-
- Posts: 469
- Joined: August 30th, 2012, 4:27 am
Re: Javascript Performance Thread
The new & official code name for JIT-v2 is ThreeHeadedMonkey.
What a name
-
- Posts: 471
- Joined: February 25th, 2013, 9:52 pm
Re: Javascript Performance Thread
can anyone on IRC go on and see what http://search.mibbit.com/networks/Mozilla/%23jitv2 is about?
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
I haven't asked, but there's been no activity since yesterday. I'm guessing it's for planning an event discussing JITv2/ThreeHeadedMonkey (though I'm still not clear on what that is).mayankleoboy1 wrote:can anyone on IRC go on and see what http://search.mibbit.com/networks/Mozilla/%23jitv2 is about?
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
Pretty exciting progress in bug 1242691, which is about a case where minor GCs take a long time to complete. Minor GCs are supposed to be quick and happen frequently, to empty the GC's "nursery" for short-lived objects (and put anything that's still alive in the regular GC heap), but here they're taking upwards of 40 milliseconds and causing a lot of jank.
I think this is the most common remaining performance cliff for the GC - I'm not sure how often it happens since it involves large arrays, but minor GCs that take a long time defeat the purpose of having them at all. With the patch in the bug, these >40ms minor GCs are reduced to 4ms minor GCs (the total runtime of the testcase is reduced from 10 seconds to 1.5 seconds), and it increases our score on Octane by a 1000 points to boot.
Edit: No visible bump on AWFY, which is odd. Hannes Verschore (h4writer) asked about this in the bug - perhaps something broke before landing, or maybe there's some other configuration difference responsible.
Edit2: The speedup on pdf.js may have been noise, or due to the patch in bug 1233857, which hasn't landed yet. The speedup on the CodeMirror testcase stands, however.
Edit3: Further tests confirm that the big win on Octane does come from bug 1233857, so both bugs improve different situations. But the win is real!
I think this is the most common remaining performance cliff for the GC - I'm not sure how often it happens since it involves large arrays, but minor GCs that take a long time defeat the purpose of having them at all. With the patch in the bug, these >40ms minor GCs are reduced to 4ms minor GCs (the total runtime of the testcase is reduced from 10 seconds to 1.5 seconds), and it increases our score on Octane by a 1000 points to boot.
Edit: No visible bump on AWFY, which is odd. Hannes Verschore (h4writer) asked about this in the bug - perhaps something broke before landing, or maybe there's some other configuration difference responsible.
Edit2: The speedup on pdf.js may have been noise, or due to the patch in bug 1233857, which hasn't landed yet. The speedup on the CodeMirror testcase stands, however.
Edit3: Further tests confirm that the big win on Octane does come from bug 1233857, so both bugs improve different situations. But the win is real!
-
- Posts: 7
- Joined: June 27th, 2003, 9:35 am
- Location: Isokyrö, Finland
- Contact:
Re: Javascript Performance Thread
Do you still consider the bolded part a valid advice for today's (nightly) garbage collector? I was going through my user set settings on about:config and remembered your post from way back.On Wed 31st Dec 2014 Ver Greeneyes wrote:Yeah, there were a few big improvements recently.
Bug 1084672 - Slice 1 of a GC lasts 40ms with asm.js game fixed an important heuristic to work correctly with OMTC. This bug was causing 40ms slices even while painting.
Bug 1052793 - Do per-zone GC for CC_WAITING triggers changed GCs triggered from Gecko's Cycle Collector to not be full GCs all the time. This means we do single-zone GCs instead of full GCs (hundreds of zones for a few tabs or thousands of zones for a lot of tabs) a lot of the time. There's still more to gain here with Bug 1110928 - Per-document GC poking should not trigger a full GC, which I'm hoping Andrew will finish soon.
Bug 1072564 - Incrementalize type information sweeping incrementalized another stage of GC, which should have reduced max pause times (I don't have numbers on its impact though).
Bug 989390 - Start background sweeping as soon as arenas are available to sweep probably reduced the amount of time that the main thread GC has to wait for background sweeping to finish, though again I have no numbers. This is more important for compacting GC, which adds another stage after the others (but isn't enabled on any GCs yet).
There's a few remaining known issues that I know of, which are summarized nicely in Comment #5 of Bug 1111361 - Dropped frames in Canvas Animations; presumed caused by GC pauses. Aside from a few bugs, if you have a fast PC you can probably reduce pause times by disabling javascript.options.mem.gc_dynamic_mark_slice (which doubles slice times during periods of heavy GC) or by lowering javascript.options.mem.gc_incremental_slice_ms (which is the slice time that should get used whenever the browser is painting regularly).
With the current defaults you can get 20ms slices during periods of heavy GC, which is obviously too much for 60fps, but we're not quite at the point yet where it would be wise to reduce the slice time for everyone. But if you have a fast PC, you could try disabling javascript.options.mem.gc_dynamic_mark_slice and setting javascript.options.mem.gc_incremental_slice_ms to 7 or 8ms to see how it feels. If your PC can't keep up this might lead to excessive GCing though, so do this at your own risk.
I started testing different values for javascript.options.mem.gc_incremental_slice_ms with javascript.options.mem.gc_dynamic_mark_slice set to false. The thing is, I'm not really sure how to benchmark these settings, so that they would be optimal for my computer.
TL;DR: Unless there is some automated tool to do the benchmarking, what values for these settings would you recommend today? Also, is there some other GC settings worth fiddling with, if you got extra cpu power or plenty of memory? For example, is there any benefit in raising javascript.options.mem.high_water_mark, or is that just waste of memory?
-EDIT2: Deleted a wall of text describing how I tried to benchmark those gc settings. TL;DR2:It didn't work, it wasn't worth reading and I don't have any idea on how to do it better.
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
Hmm, in theory things have only gotten better since then, so there's less chance of things going off the rails if you lower the slice time. I think the main thing to consider is your monitor's refresh rate. Firefox paints in sync with Windows' compositor now, so it should be able to get very stable frame rates, but it needs to have enough time to do calculations between frames. When a GC is in progress, we do one incremental slice per frame - so the value of javascript.options.mem.gc_incremental_slice_ms determines how much time it will have to do other stuff. With a standard 60Hz display, there's a period of 16.67 milliseconds between refreshes, so the default setting of 10ms per slice only leave 6.67 milliseconds.wiFFy wrote:Do you still consider the bolded part a valid advice for today's (nightly) garbage collector? I was going through my user set settings on about:config and remembered your post from way back.
While a GC won't always be in progress, lowering the slice time might allow Firefox to get more done. Setting this to 8ms gives a little over 50% of the time to the 'mutator' (anything that isn't GC, basically), which is more reasonable I think. But set it too low, and the GC might fall behind allocation, eventually leading to a full GC that causes a large pause. javascript.options.mem.gc_dynamic_mark_slice helps the GC avoid falling behind, but at the cost of doubling its slice budgets. So for a smooth experience, you don't want that to trigger. It would be nicer if slice times were adjusted more dynamically to either maintain 60fps or 30fps, or something like that, but other improvements still have priority.
Anyway, that's about it. I don't think changing the high water mark or any of the other limits is going to really help - it will delay GCs from happening, but if there's a lot of garbage to collect you'd rather GC sooner than later, since a bigger heap means longer GCs and more allocation overhead. I can't really tell you how to test new settings, except that if you're seeing a lot of long pauses, the GC is probably falling behind, so you need to raise the slice budgets. But the Cycle Collector can also still trigger full GCs in some situations, so it's not a foolproof test.
-
- Posts: 269
- Joined: February 7th, 2013, 3:19 pm
Re: Javascript Performance Thread
Edge made a huge Octane jump with its new release on AWFY! Improvements on ALL subtests!
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
Yes, quite impressive! Edge isn't updated that frequently, but they clearly made a lot of changes since the last update.Timvde wrote:Edge made a huge Octane jump with its new release on AWFY! Improvements on ALL subtests!
Pretty much all the bugs I mentioned earlier are still in flight, but I wanted to mention two new developments: Tom Schuster (evilpie) is looking into optimizing ES6 Proxies (bug 1245974). These are still fairly new, but will probably be used more and more heavily in the future, both on the web and in Firefox itself (for a recent example in Firefox, see bug 1241837 - although I'm not sure how performance sensitive that case is).
Similarly, Eric Faust (efaust) is looking into optimizing the common cases for Cross-Compartment Wrappers (CCWs) in bug 1245987, which Firefox uses internally to mediate secure access between JavaScript 'compartments' (a SpiderMonkey concept, but a very useful one for security). Cross-compartment access has been a pain point for SM performance for a long time, so it's great to see this being addressed!
-
- Posts: 471
- Joined: February 25th, 2013, 9:52 pm
Re: Javascript Performance Thread
any update on Threeheadedmonkey/Jit-V2 ?
-
- Posts: 1030
- Joined: June 28th, 2008, 4:57 am
Re: Javascript Performance Thread
Sort of. Nicolas Pierron (:nbp) explained on IRC that the idea is to split compilation workloads across multiple threads. He has some slides for it (I haven't seen them), but right now it's still in the conceptual stage as far as I know - no code has been written yet.mayankleoboy1 wrote:any update on Threeheadedmonkey/Jit-V2 ?
That fix for the performance pitfalls for minor GCs landed, but unfortunately it didn't make a difference on AWFY. Still, the testcases that these fixes were developed to improve are tremendously faster, so it might well be making a difference to Firefox's overall performance in some cases (mostly regarding the dev tools, I believe, which would be pretty handy).