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)."
Look dude, Get your complaints right. You're bitching about Memory Footprint. Perfectly acceptable problem to bitch about.
You're not bitching about memory leaks. Memory leaks would be indicated by progressive increase in the amount of memory used over time, without functional changes is your usage of the app. That's not what's indicated by my tests on both Windows and Mac. I run with many tabs open, and FF's memory usage is directly related to the number of tabs I have open. When I shed a window or a set of tabs, FF shrinks in memory footprint.
If you were bitching about memory leaks, that would be a perfectly reproducible problem, and a standard memory profiler would catch these things, and any contributor to FF could easily submit patches to clean up the leaked memory. Memory bloat is a more systematic problem that is much harder to keep a handle on. No matter what, new features need memory to work, so as an application ages it would be prone to increase it's footprint. That's the hard problem, and that's what I think the FF team should take some time to focus on, now that they are reaching acceptable responsiveness in general.
Gravity Sucks
I think that the lack of guided optimization on gcc is a fair indication that Microsoft offers a better compiler, but I also think it's a long way from "gcc lacks an option that helps Firefox" to "Linux is for masochists". Seriously, Firefox scored better on some JS benchmarks on Windows than it did on Linux, but that doesn't make the Linux version unusable or painful.
Anyway, many of us don't use GNU/Linux because it is unfailingly better than alternatives, but because we have an understanding of and appreciation for economic and intellectual liberty which is better served by GNU systems. We regard the use of proprietary systems to be masochistic.
Install FF 4, browse a while, close all but one _blank_ tab and guess what? Firefox uses 7-800 MB _active_ memory.
Hi, I'm a Firefox dev. That sounds very bad. Can you please give some more details about how to reproduce it: Are you using a new profile? Are there any addons and plugins installed? What websites do you visit? And what specific Linux distro are you on?
Note that this might not be a bug: For example, if you visit a website that shows 200MB of images, then close that tab, then the memory is not necessarily freed. The reason is that the page stays cached, so that if you do 'History->Recently closed tabs' and open it, it will appear quickly. On a machine with lots of memory (most these days), that behavior tends to work better than releasing pages aggressively. However, if you aren't visiting websites with extreme memory use like that, then this might be an actual bug.
Getting back to your problem: With a new profile and no addons or plugins, we are unaware of a bug that causes anything like that. So I would be very grateful to you if you can point us to a bug we don't know about, so that we can fix it. If you give me steps that I can use to reproduce the problem (on my Linux machine over here),then you have my promise that I will l personally look into this and do everything in my power to fix it.
Does that mean they weren't using a profiler before now?? That... actually explains quite a bit...
No, we use profilers ;) In fact we have some valgrind - the awesome Linux profiling tool - devs working here.
Profile guided optimization is something else though. It is a special way of compiling and linking, that the compiler and linker use profiling information to know how best to optimize the code. So code that is used a lot is compiled with -O3 (the most optimizations), while code that is not used a lot gets -Os (to take less space), and so forth. This is a very useful technique that was not available on Linux until last year, and the news today is that Firefox now builds properly with it and there is a nice noticeable speed improvement for Linux users.
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.