I don't think I've ever run any asm.js other than demos.
PS: I just ran Octane 2.0. The SplayLatency test looks like it's designed to test what I'm talking about; I get 25k in Chrome, but only 9k in FF. http://developers.google.com/octane/benchmark#splaylatency
A bunch of people reckon it doesn't matter - see e.g. https://news.ycombinator.com/item?id=8519507 - but I think it does. GC pauses are very noticeable when there are realtime constraints, like animation.
Perceived performance depends on a lot of things, not just JS speed and consistency - also graphics, UI responsiveness, etc. Chrome has had an advantage in some of those areas, but the difference is pretty small at this point, especially if you are on Firefox Nightly.
I think we definitely need some GC throughput/latency benchmarks in the standard suites.
SplayLatency computes the root-mean-squared allocation time, and your final score is the reciprocal of that, scaled by some constant. Let's call the RMS measurement the "badness"; more badness is worse on this benchmark.
Say you're allocating 1000 objects and object allocation itself takes 0 time so all that's being measured is the GC. You plan to GC them all before your JS runs to completion. You consider two alternate strategies.
One strategy is to perform a GC run every 10 allocations, each of which collects 10 objects. For simplicity, say each GC has 1s of overhead and takes 1s per object collected. So each of your GCs will take 11s. So you will have sqrt((100 * 11^2 + 900 * 0)/1000) = sqrt(12.1) as your "badness" score on the benchmark, and will take 1100s to finish.
Now the second strategy: one GC every 100 allocations. Now each GC takes 101s, and it only takes 1010s to finish. But the splay "badness" score is sqrt((10 * 101^2 + 990 * 0)/1000) = sqrt(102.01).
So per the benchmark the better strategy is the "GC more often" one. But for animations the _second_ strategy is better in this case, because the animations can't run while the JS is running to completion anyway. So as long as both strategies are collecting all the garbage before run-to-completion finishes, the one that's better for animations is the one with higher throughput. But that's the one Splay scores worse.
Back to the real problem we're trying to solve: what hurts animations is a GC strategy that aims for higher throughput by letting garbage pile up across multiple runs to completion and then ends up with a long GC pause at some point. Having a benchmark that penalized that sort of GC strategy would in fact be a good idea. But Splay is not that benchmark. In fact, the optimal GC strategy on Splay is to not GC at all until the benchmark finishes and then do one big GC that takes forever but isn't measured as part of the benchmark time.
Basically, SplayLatency sets up perverse incentives where the simplest ways to do better on the benchmark involve making animation pauses _worse_.
It's also possible to improve the score on SplayLatency by actually improving the throughput of your GC, but that's a lot more work than the other approaches, and just as likely to regress this benchmark if you do it by chunking your GC more within a single run to completion.
The end result is that improvements to this benchmark's score have little to do with reduction of user-visible GC pauses.
You can see some more in-depth discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=958492 but the above basically summarizes what's going on. The fix in that bug ended up just shuffling work around within a single run to completion to placate this benchmark, and the hard part was doing it in a way that didn't regress things too much for actual real-life animation use cases...
Once I'd installed the corresponding Firefox add-ons, the UI became too unresponsive too often for me to put up with it.
It sounds to me like one of the plugins probably has a bug.
Recently made the switch to Opera and it has been much better than chrome or firefox. Opera is based on webkit, so it renders just like Chrome, has the same web dev features, and you can use almost all of chromes extensions in Opera. On top of that, I find Opera to take out a lot of the annoyances I've had with Chrome. Also Opera doesn't track you like Chrome probably does, and it's not hindered by Google's politics.
Opera is actually based on Blink, Google's fork of WebKit, so it does inherit Google's politics, and contributes to Google's monopolization of web standards.
Make sure to let all the Opera devs working on web standards know this. It'll save them a bunch of hassle to know they're just wasting their time!
You can't advance the open web with FUD.
I don't mean to denigrate their work, nor have I forgotten Opera's role in the fight for web standards, but in the case of Blink, their contributions pale in comparison to Google's. Check the graph at http://browserg.nom.es/#commitsByOrganization, and note that the vertical axis is not linear.
Opera's commit volume to Blink is 7% of Google's. Hell, Samsung is landing nearly twice as many commits.
An implementation monoculture is bad for openness and interoperability. We've been there once with Microsoft, and we legitimately risk going there again with Google. See, for instance, Google unilaterally shipping Shadow DOM, on by default, before standardization. "Chrome will be shipping Shadow DOM publicly. [...] If you want to suggest name changes, as we brainstormed a bit at the f2f, do so RIGHT NOW or forever hold your peace." http://lists.w3.org/Archives/Public/www-style/2014Feb/0103.h... (HN discussion at https://news.ycombinator.com/item?id=7184912)
I don't want a web where any vendor has that much weight to throw around.
With my Mozilla developer hat on, that happens not to be the case. Which you would have known had you either read the entire linked-to thread, or even just read the mail that was linked to, which points that out explicitly in the "notwithstanding your apparently inaccurate statement about Mozilla" bit.
> That was literally the next statement where you cut your quote.
It was also a misrepresentation of what's actually going on. Quite common out of Google these days, unfortunately; we've had to call them on it publicly a number of times. Not that this is stopping them from continuing to claim that others are OK with something they're doing when that happens to not be true.
> but all the talking and consensus building was done
The only thing discussed at the CSS working group f2f was the cat and hat combinators, not the entire shadow DOM spec. And even for those, serious issues were raised later by people who were not present at the f2f.
For shadow DOM as a whole, there is no consensus at all. Mozilla is not really on board with the spec in its current form (and we've said so repeatedly and publicly, though we do at least have a plan for how to get the spec to something that we'll be OK shipping... which won't match what Google is shipping). Apple is very definitely not on board at all with the spec in its current form, and Google is not even trying to get them on board. Microsoft has basically said nothing apart from having concerns.
In addition to that, the spec doesn't match Google's implementation at all, in all sorts of ways that are obvious if you actually stop to read what the spec says.
Basically, Google implemented and shipped whatever they felt like and made a sort of attempt at specifying something or other which totally doesn't match what they shipped. And other UA vendors at best (Mozilla) plan to ship something somewhat different from what Google has shipped and at worst (Apple) think the whole thing needs to go back to the drawing board because it's just broken by design.
If you don't think that's unilaterally shipping before standardization, I'm not sure what you think it is, exactly.
* Opera's extension store has Youtube Center, which google disallows in it's store.
* When you highlight text and want to search it, Opera lets you search using your default SE, and then a second option to use something like duckduckgo, amazon, wikipedia, etc..
Chrome seems faster for most high performance sites I visit and crashes less often. However, I prefer to have less of my browsing data recorded and so primarily use firefox and duckduckgo.
https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
I use it with Tab Mix Plus for extra tabby features, like progress bar on the tab, tracking unread tab state, lots of undo close tab slots, forcing popups to show up as tabs, etc:
https://addons.mozilla.org/en-US/firefox/addon/tab-mix-plus/
The tab panorama feature is built in:
https://support.mozilla.org/en-US/kb/tab-groups-organize-tab...
If you're primarily interested in speedy javascript, process isolation across tabs (so busy tabs don't lock out the UI), or debugging web apps, I think Chrome is better. Chrome in particular seems to have a much smoother JS execution profile; it may be down to GC, or something else, but Chrome generally has fewer frames dropped for any given demo.
On the other hand, Firefox is way more featureful, and has a better library of extensions. I find it very difficult to configure Chrome to be how I like it - with a bookmarks menu, zero history, and tree style tabs - whereas Firefox is much easier to shape to my purposes. The combination of tree-style tabs and tab panorama means I can - and do - keep in excess of a hundred tabs open without any difficulty in management.
So Firefox is my primary browser, and Chrome is strictly for testing and pseudonymous browsing.