Firefox On Linux Gets Faster Builds — To Be Fast As Windows 306
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)."
YES! (Score:5, Interesting)
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 (Score:5, Interesting)
What about distributions (Score:5, Interesting)
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 (Score:1, Interesting)
Re:But the memory leaks still aren't fixed. (Score:3, Interesting)
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.
Re:Every improvement is highly needed, FF4 sux (Score:5, Interesting)
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.