[barrkel]

It depends on what you want.

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.

[TazeTSchnitzel]

Firefox's JS is pretty speedy too though, and it's faster than Chrome for things compiled with emscripten due to asm.js, like every Humble Mozilla Bundle game, anything made with Unity or Unreal Engine, anything using stuff like sql.js or other C libraries, etc.

[barrkel]

Benchmarks tell me that Firefox's throughput is better at this point, and I have no reason to doubt it, but I also know from direct experience that variance in performance is far, far higher with Firefox.

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.

[azakai]

Yet in the other latency test in Octane, MandreelLatency, Firefox does about 50% better than Chrome.

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.

[cromwellian]

Isn't Mandreel just another Emscripten style test that avoids the garbage collector in favor of typed arrays?

I think we definitely need some GC throughput/latency benchmarks in the standard suites.

[azakai]

Mandreel doesn't avoid garbage as much as emscripten output does, but it does create less than "typical" JS, most likely. However, it still can create plenty of doubles as garbage on the heap, on JS engines without nanboxing, such as v8, which is a factor in why v8 loses here.

[bzbarsky]

Here's the problem with SplayLatency.

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...

[ultramancool]

Yeah, I think the main benefit of Chrome these days is mainly about UI performance more than anything else. They achieve that extremely well with the process isolation. Firefox is moving in that direction to with their electrolysis project, so it'll be interesting to see where that goes.

[cbd1984]

IME, Chrome is slower in terms of UI responsiveness, especially when starting up (massive disk usage) and switching tabs/making new tabs (pegs at least one core of my CPU, whole browser goes catatonic).

[singlow]

IME chrome is faster when I have enough RAM. I have a notebook with 16G of memory and Chrome runs great on it- seems quicker than Firefox. But on my workstation I only have 8G and usually have more things fighting for it. When memory is low Chrome gets unusable but Firefox keeps going along at its not-quite-as-fast-as-chrome-with-enough-memory pace.

[mrottenkolber]

16G and chrome runs great on it. What the shit guys.

[mschuster91]

Usually chrome's UI stickyness goes away when you either buy more RAM or install a SSD instead of a HDD. Chrome's disk usage is crazy.

[cookiecaper]

I find that Firefox is currently faster for everything except 3D stuff. It may be a driver thing (nvidia on Linux).

[grumblestumble]

I'm personally of the opinion that Chrome has jumped the shark with it's emphasis on perf benchmarking and profiling tools. There's no doubt that Chrome's Dev Tools are superior to anything else out there, but real-world usage has suffered. I've seen instances where certain layouts (eg: position: fixed) cause the visible UI to get out of sync with the DOM, then 'magically' correct itself as soon as you inspect element - no doubt an artifact of over-optimizing repaints. Chrome's Pepper Flash plugin is also considerably less performant than Adobe's plugin, with multiple Chromium tickets spanning over a year. As one of the comments lower down indicates, it's awesome if you're running the latest MBPro with 16G RAM, but should you really need that for a browser? And don't even get me started on Chrome/Windows - have they finally decided to render custom fonts in a way that doesn't look like absolute crap? The Chromium thread on that bug was very insightful as to how the Chrome devs view their user base. Additionally, when it comes to rendering CSS3 effects (gradients, shadows, etc) Chrome really performs poorly compared to Firefox or Safari. Radial gradients esp. suffer from extreme banding, even on Retina displays.

[psychometry]

Firefox certainly has a larger library of add-ons and those add-ons are more powerful than ones available from Chrome in terms of customizing the browser. The problem is that once you install all the add-ons you're accustomed to having in Chrome, Firefox slows down enough that it's not even worth it. This was my experience using FirefoxDeveloperEdition for the past month and although I miss Firefox's far superior address bar and customizability, the huge performance hit just wasn't worth it and I switched back to Chrome.

[swift]

Which add-ons did you have installed?

[psychometry]

In Chrome: 1Password, AdBlock, a Gmail checker, a cookie editor, FlashBlock, Ghostery, Hacker News Enhancement Suite, Imagus, Reddit Enhancement Suite, Stylish.

Once I'd installed the corresponding Firefox add-ons, the UI became too unresponsive too often for me to put up with it.

[zxcvcxz]

I have most of those installed (plus some others) in FF Nightly and I'm running fine.

It sounds to me like one of the plugins probably has a bug.

[Noxchi]

Chrome started being annoying for me after version 36, but firefox was bad too.

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.

[callahad]

> 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.

[magicalist]

> 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.

[callahad]

> Make sure to let all the Opera devs working on web standards know this.

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.

[rblatz]

You purposely cut out that they are shipping shadow dom in conjunction with Mozilla. That was literally the next statement where you cut your quote. And if you continue to read the conversation this was all talked about and is basically a draft spec, they just haven't finished writing it up, but all the talking and consensus building was done and documented in the f2f minutes.

[bzbarsky]

> that they are shipping shadow dom in conjunction with Mozilla

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.

[woah]

Been waiting for shadow Dom for years now.

[Noxchi]

What I meant by that was Opera lets users do what they want, and doesn't try to hinder them like google does when certain features are against their interest. Things like:

* 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..

[rifung]

I believe the person you're responding to was referring to how Google inherently wants to track users due to their business model, although I think you bring up a valid point.

[paulhebert]

Yeah, they both have different benefits.

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.

[blaze33]

Can you recommend any particular Firefox tree-tabs or tab panorama addons ? I don't know how I went this far without this...

[barrkel]

Tree Style Tab:

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...