Seems like that has no doubt been an important part of the deal that Yahoo! and Mozilla made. It's an interesting way to get back at Google's heavy promotion of Chrome on their properties.
To be perfectly honest, I'm sick of Chrome being pushed down my throat at every turn (including in emacs-w3m; if I'm using emacs-w3m, I'm pretty damn sure I know what Chrome is and I consciously choose not to use it). Yes, I know it's their baby, yes I know it's their SE; but this headline brought a wry smile to my face. Turnabout is fair play :P
I mean, they probably just detect if your user agent is not Chrome. It'd be silly to complicate it further by checking if it's not some relatively obscure thing that's super techy just for the benefit of excluding people that will for sure not use Chrome.
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.
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.
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.
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.
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.
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.
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...
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.
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).
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.
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.
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.
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.
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.
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.
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.
> 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.
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..
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.
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.
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:
I've been using $RELATIVELY_FRESH_BROWSER_INSTALL again recently. I stopped when it was slower and less stable than $BROWSER_I_HAVE_NOW_BEEN_USING_A_LONG_TIME.
These days it often feels faster than $BROWSER_I_HAVE_NOW_BEEN_USING_A_LONG_TIME.
Yes, it would. It's not based completely on performance gains you may see in new updates. Profiles bloat up over time with data (history, cookies, cache, etc) and the bigger it is, the more the browser has to process. So, over time, your browser will slow down. A fresh install of a new browser would result in all this data not existing. If it doesn't have to parse hundreds of megs of files, it'll generally be faster.
All of those things are easily cleared, however. If I do a clear history/cache/cookies in Firefox, there's still a lot of miscellaneous data floating around in my profile, to the point where, last I recall, the Firefox team still recommends you outright dump your profile in case of difficulties.
There is nothing inherent in the design of A hypothetical browser that would make it slower over time, its just a matter of people make assumptions and those assumptions are often wrong, and then performance suffers.
Some things do accumulate. That is in fact the point of Firefox Reset[1].
The support page lists "Extensions and themes, website-specific preferences, search engines, download history, DOM storage, security settings, download actions, plugin settings, toolbar customizations, user styles and social features will be removed."
Installing extensions can dramatically slow down browsers. I wonder if the lack of extensions is responsible for the quickness users experience with a fresh install.
Absolutely – there's really common cycle I see repeated all over:
1. “(Firefox|Chrome) is slow”
2. “Did you try removing Ad-Block Plus, etc.?”
3. “Now it's fast again!”
I think we're well past the point where the browsers are going to need to start having some UI around monitoring and exposing slow extensions to make it easier for users to learn this.
Absolutely. When I first starting using FF and all the developer tools, it would grind to a halt. Now that I'm a lot more comfortable with the FF toolset, I have a minimal set of extensions and it feels much snappier.
I also use Aurora which is still super fast to me. I also develop with Chrome Canary and the stable Chrome version. Canary has times when its totally useless or when someone breaks the build and I can't use it for a week so until the next update comes out.
All in all, yes, less overhead means a snappier browser to me.
That's my biggest reason for switching from AdBlock+ to Privoxy + https://github.com/skroll/privoxy-adblock . Same blocking rules but uses a ton less memory, since each tab isn't running all of AB+ .
That's fine for image and flash ads, but provides no support for CSS blocking of elements. My understanding is that the CSS blocking is the slowest part, too.
I've been using Firefox for several months and have no regrets. On Ubuntu Chrome was doing all sorts of weird things, plus being slow. Firefox's tab groups is also a great feature.
On my Linux MINT machine, chrome keeps doing something[1] that ends up locking up my whole machine and I have to hard-reboot. It got to a point where I actually had to set up Ctrl+Alt+K to issue "pkill -9 chrome" so as soon as I see the mouse-pointer movement become non-smooth or music start to skip, I slam on those keys to kill chrome before I have to restart my whole machine. Then I just went to Firefox developer edition[2]. Is it better? I dunno, but I like its cool dark theme, my system hasn't locked up since and now I got all those cool extensions back again.
I had that problem with Linux Mint on some configurations too. I found that by going into chrome://flags/ and disabling everything related to GPU acceleration the crashes went away. YMMV, of course.
The discussion is about Google Chrome not working on Linux Mint. I said that Google Chrome works for me on Linux Mint. How is that not relevant?
I'm not saying there's no problem, I'm just offering my experience to demonstrate that perhaps the problem isn't just "Chrome runs poorly on Linux Mint", and to offer a counterexample to "Linux Mint is a buggy mess".
I can second the Ubuntu motivation. Chrome is buggy and unreliable on Ubuntu, and I was tired of the Aw Snap several times a week. Firefox appears to be much more stable, and Developer Edition looks better too.
I switched back to Firefox recently as well after using Chrome for years. Mostly it was due to problems on Linux, like Flash not working. I also love the work Mozilla has been doing -- Rust, Servo, and asm.js in particular -- which seem to be very promising vis-à-vis future versions of their browser.
Firefox won't have a process per tab. Even in the multiprocess versions, it has one process for the UI and one for all the tabs' content. That way it doesn't take tons of RAM for overhead if you have lots of tabs, but heavy tab content can't freeze the UI. You can change the number of tab-processes in about:config under dom.ipc.processCount.
Another advantage of using one process for all tabs is that Firefox can take advantage of security sandboxing of the content process without the overhead of tons of per-tab processes. (Quite a few Firefox users like using hundreds of tabs. :) Eventually Firefox will tweak the tabs/process balance to find a good compromise.
Firefox uses compartments per domain instead, which is a great alternative to process per tab:
"Some readers might wonder how compartments compare to per-tab processes as they are used by Google Chrome and Internet Explorer.
Compartments are similar in many ways, but also very different. Both processes and compartments shield JavaScript objects against each other.
The most important distinction is that processes offer a stronger separation enforced by the processor hardware, while compartments offer a pure software guarantee. However, on the upside compartments allow much more efficient cross compartment communication that processes code.
With compartments cross origin websites can still communicate with each other with a small overhead (governed by certain cross origin access policy), while with processes cross-process JavaScript object access is either impossible or extremely expensive.
In a modern browser you will likely see both forms of separation being applied. Two web sites that never have to talk to each other can live in separate processes, while cross origin websites that do want to communicate can use compartments to enhance security and performance."
Yeah, they have a MemShrink team now. https://wiki.mozilla.org/Performance/MemShrink They got serious about memory leaks in their own code, and even took steps to limit hogging by 3rd-party plugins. Now they host https://AreWeSlimYet.com/ to track regressions. Edit: and Chrome really does take a ton of RAM if you have lots of tabs open.
"and Chrome really does take a ton of RAM if you have lots of tabs open."
Yup, it does. My problem with FF years ago was with leaks. It would eventually bring my entire system to a state of paging hell until I killed it. That was years ago though, I've since become comfortable with chrome and haven't found aneed to go back.
Nope. Pinch to zoom "works", but it's the same zoom increments as Ctrl - and Ctrl =.
I've been using Firefox for a few years (switched back from Chrome), but it's IE for me on the Surface until someone else does proper touchscreen support. The only time I open Firefox on here is when I need a bookmark that's synced from my desktop or phone.
I was using Firefox in the past few months because Chrome felt slower after the new update.
I am back to using Chrome however. It's really hard to break the habit even though I made it a conscious effort to use Firefox and have enjoyed it thoroughly.
My only gripe with Firefox would be watching youtube I see a Adobe process that takes up a lot of memory even though I force HTML5, it seems to revert to Adobe.
All in all Firefox is the Chrome browser I once loved, but now that Chrome is working back to what it was doing, I forgot about Firefox.
Anecdotal and all but these days i catch myself killing chrome because the computer fan starts to be loud - and reopen the page in firefox - fixes it everytime (granted, i check it is the issue with htop first).
I remember when this was the exact opposite and had to kill Firefox...
how is having more features and options not being an upgrade?
chrome is removing customization after customization (specially the ones that harm google business model. Referrer preferences, anyone?) while adding stuff for speed and network. So you have a fixed experience browser that is very fast. and not that firefox is not faster in most use cases anyway. Chrome just have better marketing (and arguably a head start on speed a long time ago)
For some heavy users, including me, Firefox has always felt better.
I've honestly tried to switch to both Opera and Chrome but once you are spoiled with real extensions there is always one of them holding you back. ATM the most obvious one is treestyletabs.
This is not to say that there is not a lot of people to whom Chrome is better. Just that you can rest assured that Firefox is better as well, -for some of us, just like Safari is the best browser for some people and others want Opera. (Same goes for Linux, Mac and Windows and I love being able to chose one that I like.)
I wear both glasses and contacts, I regularly upgrade from one to the other because I am annoyed by a particular aspect of each. Much the same with browsers I regularly switch between Safari, Chrome, and Firefox because the upgrades/site/support/whatever become troublesome or advantageous.
When in doubt people should interpret it in a way that is convenient to them and not others. It makes total sense for Yahoo! to promote Firefox as a "Better browser". Google in past too has tried similar tricks.
This is a very broad statement. I use both browsers because each has slightly different behavior in some edge cases that I prefer. To me, firefox is occasionally an upgrade, and chrome occasionally is.
