Hacker News Reader

Comment by btipling | Hacker News Reader

On Sunday, using my latest version of Firefox, I opened a single page loading it only once to check how it looked in Firefox. Then I forgot I had Firefox open for the rest of the day. Eventually my Macbook Pro became slow and looking at Activity Monitor I saw Firefox was taken hundreds of MB of RAM and just eating some 20-30% of CPU% just idling there.

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.

View on HN

Every time I use Chrome, my Macbook Pro becomes slow and everything pages to disk. It's snappy when it starts, but in Chrome 20 or whatever crazy version number they're on now, there's still a lot of leaks. It's very frustrating.

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.

IIRC both Google's and Mozilla's browser metrics showed that a vast majority of users (>90%) never open more than 5 tabs simultaneously. Chrome is optimized for this use case, both from a memory as well as interface perspective. So for most users it works very well, better than the competition I daresay. Unfortunately it tends to completely break down once you go too far out of its comfort zone (i.e. using many tabs). Unless you have immense amounts of memory (> 4 GB) the gigantic memory use will not only affect Chrome itself but also all other programs as the OS starts swapping their pages onto the hard disk (which have to be swapped back upon access which is slow). Additionally, the interface was clearly never intended to be used with too many tabs as it lacks any kind of tab overflow concept. And the interface starts to lack badly which for me is an indication that there are bottlenecks in the single browser process which handles the UI.

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.

You're right, but most people will not notice Chrome's sluggishness because Google has worked very hard to ensure Chrome feels fast. That, and (in my experience) the fact that most Chrome users rarely go beyond 15-20 open tabs, make Chrome an overall better experience than Firefox for many people. In UX design, perception of speed counts almost as much as actual speed.

The key for that is that the UI is in a separate process. Firefox for android (Nightly and Aurora) also do that.

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.

Actually in Firefox for Android the UI is just on a different thread than the web content, not in a different process.

V8 is ACTUALLY fast and has been for years. I don't know how that could even be contested. Mozilla internally knows that v8 was/is fast and has been trying to beat them.

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.

http://arewefastyet.com/old-awfy.php

http://arewefastyet.com/

I am quite aware of v8 and how Mozilla is "trying to beat them". I worked on Firefox's JIT.

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.

I've noticed substantial improvement using Chrome in real-world use cases. The optimizations I've experienced happen in larger apps that hold much more in memory (I don't consider Facebook/Gmail/Wordpress especially object intensive or CPU intensive, do you?).

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.

"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

Also relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=539356

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.

> I've noticed substantial improvement using Chrome in real-world use 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.

That's pretty much my experience, with one additional issue that really keeps me coming back to Firefox: Chrome doesn't handle sleep and wake-up well.

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.

On Linux and Windows, Chrome used to be significantly faster. Especially on Linux, where Firefox was honestly miserable to use. Now it's just a little bit faster to start up, and is just a little bit snappier.

The OS X ports of both browsers are a little bit infamous for being iffy, aren't they?

Almost every Firefox thread has a comment like this. I'm no Firefox expert, but I use it a lot. The most common question asked in response is:

   What extensions are you running? Can you disable some of them.

I run ABP, Ghostery, HTTPS Everywhere, Firebug. No probs wrt memory.

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.

For #2, try Vacuum Places Improved:

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

FYI, firefox does this automatically (although doubtless the exact behavior has changed since 2009).

https://bugzilla.mozilla.org/show_bug.cgi?id=512854

Thanks! I'm trying it right now.

As I mentioned, I only opened a single page. This page had no JavaScript. I only loaded it once. I only have Firebug, 1password and xmarks installed. But it doesn't matter, Firefox is a slow memory hog, it has been since 1.5.

I heard it for v2, for 2.5, 3, and 3.5 and now of course whatever crazy version number Firefox is on now.

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.

Something is obviously wrong there, and as seen in many other posts in this thread, that is not the case for most people these days.

> Every time, Mozilla devs claim all the bad bugs will be > fixed in the next version.

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.

Hey, I wasn't trying to oversell this with the headline, but it really seemed like this was the memory leak that had been patched. (I especially wasnt trying to undermine the rest of the awesome work that you guys at Memshrink is doing)

I wonder if the problem isn't Mac OS specific. I've never seen anything even remotely similar on any of my linux computers.

Reply on news.ycombinator.com