Firefox On Linux Gets Faster Builds — To Be Fast As Windows

dkd903 writes "Mozilla's Mike Hommey has announced on his blog that his team at Mozilla has finally managed to get the Linux builds of Firefox to use GCC 4.5 with aggressive optimization and profile guided optimization enabled. All this simply means that we can now expect a faster and less sluggish Firefox browser on Linux (both 32 bit and 64 bit systems)."

Comments

YES!

[supersloshy]

As a long-time Firefox and GNU/Linux fan, this is excellent news. Whenever I use Firefox on even the most basic windows installs, it's always faster than my desktop running Arch Linux. It lags left and right, sometimes takes forever to switch tabs, but it's not unusable. Thanks Mozilla for remembering that you have a lot of Linux-using fans! :)

Re:I was a firefox user

[drb226]

You may want to try Opera sometime. Absolutely pitiful for extensions, not quite as standards-friendly as the open-source alternatives, but the way it renders pages is very snappy.

What about distributions

[camcorder]

I've been using Linux long before than even Firefox existed, but I don't remember downloading Firefox from their website (so their builds) for Linux since it was the de-facto browser of choice of Linux desktop. I believe most users of Firefox on Linux use build of their distribution. Not to mention that also means couple of millions less for their download count.

Though, maybe their way of doing it or updates in makefiles help maintainers of distributions to put better builds. I guess that's what matters, not their own build on web page.

Every improvement is highly needed, FF4 sux

[xiando]

Install FF 4, browse a while, close all but one _blank_ tab and guess what? Firefox uses 7-800 MB _active_ memory. Doing what? Who knows. And it becomes slow and unresponsive after using it a while. Again, close all tabs but one - and it's STILL slow and crappy. The only way to make it "ok" again is to close it and start it up again. This is on Linux. FF4 is imho the worst ever, and they are talking about FF5 and 6 now... how about making a working FF4 first? maby ff4.1, ff4.2, etc. FF3 didn't become anything near accepable until 3.5/3.6.

Re:Every improvement is highly needed, FF4 sux

[kripkenstein]

AdBlock and Firebug are both know to cause memory problems in some cases. I believe this will, at least in part, be fixed in Firefox 4.0.1 - which was launched the other day I think (maybe you already updated to it). But even so, they are good first suspects. Firefox lets addons modify a lot of internal things, which makes useful addons like AdBlock and Firebug possible, but also gives them the opportunity to (easily) create memory leaks.

In general, though, my best suggestion would be to see how things are without *any* plugins or addons. Simplest way is to create a new profile, and disable plugins and addons in it. Then browse for a while and see how things are. Odds are, you won't see strange memory behavior, and then the question is, which addon or plugin it is, and you can reenable them one by one til you find the guilty one.

Long-term, most addons will probably become Jetpack addons, which is a model similar to Chrome's. That kind of addon is more limited in what it can do, but also unable to cause memory leaks. Aside from that, we are moving to a one process per tab model, also like Chrome, will will help narrow down which page is responsible for large amounts of memory being used, when that happens. In the short term, though, problems like yours are almost always caused by addons or plugins, and I apologize for the hassle, the best thing to do is to find which it is, as I said earlier.

Re:But the memory leaks still aren't fixed.

[fbartho]

That's a good point. As we've been sandboxing things into separate processes (re: flash), it would be great if the allocator for XUL were patched so it could know which plugin is producing/using what memory. [I'm imagining "allocateWithZone" from objective-c] Then, you could have a clear panel which would indicate which subsystems are consuming more and more memory. This would allow us to point at various builds of greasemonkey (from your example) or firebug or other "fluffybunny" plugin. Further, we'd have extra data for FF crashlogs that would tell us which plugin was truly at fault in a crash, not just what thread did the crashing, but if a plugin-zone had consumed a gig of ram by itself.