But for some reason everyone has the impression that Chrome is both fast and uses less memory than Firefox, when the evidence points to the speed difference being anywhere from minimal to completely unnoticeable (I recently read a paper which suggested that Chrome's JIT optimizations have a negative effect on overall performance due to their expense). Furthermore, Firefox uses substantially less memory in general.
Extremely effective marketing on Google's part.
Firefox behaves far more gracefully in less regular use cases. With tab groups, switch-to-tab, don't load until selected and tab overflow I can easily have dozens of open tabs without affecting the performance of Firefox and the system too much while remaining quite convenient to use. Mozilla just has to improve the regular use case to be in a better competitive position. Once they've achieved this Firefox will be usable by a far wider range of possible users than Chrome.
Oh, and one of the reasons for Chrome's success (besides the sneaky bundling stuff) is probably the extremely convenient silent updater. I've installed Chrome on many computers which belong to people with little technical knowledge so I wouldn't have to bother with browser updates (users have no say in this) and outdated Flash versions (since it is bundled). Now, the latter reason wouldn't be necessary if Adobe wouldn't be such a bag of fail but that's another topic.
Of course Chrome also has a process per tab (and in fact a few more than that), but the main thing is really a separate UI process (or lockless thread for that matter).
Interestingly this is also what made BeOS so snappy. All BeOS apps require an UI thread that is separated from the rest.
All that to say, while Firefox probably won't get a process per tab, I'd like if they ported the Android UI process to the Desktop.
Chrome does use more memory if you have a ton of tabs open, but it also is still fast. I haven't noticed a substantial amount of memory leakage, but I guess that depends. Regardless, the memory leakage can be subdued by reopening a tab rather than reopening the app.
The marketing that Mozilla puts out is the problem, not Google's marketing.
As it turns out, the optimizations in v8 don't do very much above the baseline JIT except in careful microbenchmarks: https://www.cs.cmu.edu/~ishafer/compilers/files/report.pdf
The difference in speed between the two browsers in real-world code is quite minimal.
Speaking historically, you would say that Firefox 3.5 was as fast as Chrome 3 in real-world use cases? Or that Firefox 4 paralleled Chrome 10? Mozilla has been pushing that they're faster, better, ahead-of-the-curve for years and many people have switched because they haven't delivered until very recently.
Maybe only 10% of that is due to the JIT compiler but you can't easily say Chrome hasn't been faster for an extended period of time since it was released. I'm unsure of whether the remaining 90% is due to DOM interaction, rendering, or just perceived crappiness but it exists nonetheless.
A mix of all of that. For the DOM part Mozilla is developing new bindings (called Paris bindings) to close the performance gap compared to the competition [1]. Johnny Stenbeck has written two articles which give an interesting insight into past, present and future DOM bindings in Gecko [2][3]. Azure is Mozilla's new rendering API which even in its infancy showed some promising performance improvements [4][5]. Unfortunately work on Azure hasn't been progressing as fast as I had hoped. AFAIK only the canvas element is currently using Azure for rendering, the rest (ui + content) is still based on legacy APIs. On the JavaScript front there's IonMonkey, a brand new JIT compiler developed from scratch [6]. It's still in ongoing development and lacks many optimizations so right now it's slower than Mozilla's current JIT compilers in many tests [7].
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=580070 [2] http://jstenback.wordpress.com/2012/04/07/history-of-mozilla... [3] http://jstenback.wordpress.com/2012/04/11/new-dom-bindings/ [4] http://blog.mozilla.org/joe/2011/04/26/introducing-the-azure... [5] http://www.basschouten.com/blog1.php/comparing-performance-a... [6] https://wiki.mozilla.org/IonMonkey [7] http://arewefastyet.com/?a=b&view=regress
That bug is getting close to being done. It fixes a lot of crappyness with excessive layout reflows and painting.
You can see how sometimes Gecko will reflow a much larger area than needed by setting nglayout.debug.paint_flashing to true or installing the following addon: https://addons.mozilla.org/en-US/firefox/addon/toggle-paint-...
Notable cases of excessive reflows: Hovering over the sidebar links in gmail (updates almost the entire page on each hover) Hovering over "related videos" links on youtube (updates all of the related videos area, area around the video, video description, and comment area) A lot of the javascript powered animations/slideshows you see on web pages. (Again, its not uncommon to see almost the entire page being updated here) A few IE test drive tests like BetaFishIE, Santa's workshop, and the CSS maze solver.
When the above bug is fixed, Gecko should be much better in all of these cases.
And I've noticed Chrome hits the disk more often when switching between tabs than Firefox does, which makes my real-world use cases a lot slower.
Ironically, one of the applications that suffers most from this is Google Apps. I'll have calendar, gmail and half a dozen spreadsheets and documents open, move to another room, re-open the Macbook and Chrome dies on all the tabs. Firefox has no problem with this.
The OS X ports of both browsers are a little bit infamous for being iffy, aren't they?
What extensions are you running? Can you disable some of them.
Wrt CPU: are you sure you didn't have flash videos playing in a few of the tabs? :)
Btw, in my limited experience the meme that Chrome uses less memory is false. It just splits it across many processes (and IIRC this was shown recently using graphs and everything) making it harder to infer in something like Windows Task Manager.
Except wrt startup time, Firefox feels as fast (or faster) than Chrome.
Firefox needs to work on two things:
1. Raw startup time
2. speed up loading of awesomebar info after startup: even a simple-minded thing like write out the entire file under a new name every few days will probably defragment the file. it seems like that file gets heavily fragmented leading to long delays to load it. I might be wrong about the root cause.
YMMV.
https://addons.mozilla.org/en-US/firefox/addon/vacuum-places...
It gives you a button to defragment your Places database, which might greatly speed up your awesomebar. You can also set it to run automatically at startup after the browser has been restarted X times (by default X is 50, and I'm not sure that I restart Firefox 50 times in a year, so you may want to reduce this).
And each time Firefox has gotten more stable than the last. It's pretty snappy now and I can run it for days on end with no problems.
Also this patch hasn't been applied yet.
Wait a second. Did we say this anywhere this time? Read tfa; does it claim to have fixed "all the bad bugs", or even all the memory leaks?
The headline to this article says that. Sure. But Mozilla did not.
Every time, Mozilla devs claim all the bad bugs will be fixed in the next version. I heard it for v2, for 2.5, 3, and 3.5 and now of course whatever crazy version number Firefox is on now. It still sucks, but now I don't care any more because now I have Chrome.