Firefox Working to Fix Memory Leaks
Christopher Blanc writes "Many Mozilla community members, including both volunteers and Mozilla Corporation employees, have been
helping to reduce Firefox's memory usage and fix memory leak bugs lately. Hopefully, the result of this effort will be that Firefox 3 uses less memory than Firefox 2 did, especially after it has been used for several hours." Here's hoping. Frequent restarts of things on my computer make me furious. I can't imagine why anyone would tolerate such things.
everytime I mentioned the memory issue I was always told it was a plugin or there was something wrong with my system or something about my mother and a donkey. Certainly firefox fan boys wouldn't have just attacked me because I questioned something...would they? :-D
Actually, from what I understood over the last year "THERE IS NO MEMORY PROBLEM".
Every time someone mentions memory issues, the responses are either that it's supposed to consume a gigabyte of ram so that it speeds up the back button or that "there is no memory issue".
Strange, now, that there are suddenly people paying attention to specifically attacking memory use issues that supposedly don't exist.
If you can't code without hand-holding tools like automatic garbage collection, perhaps you belong in a different profession!
Firefox's problem is architectural and not one of garbage collection.
XUL is inherently single-threaded and JavaScript based. Try out any XUL application out there and you'll see how you get the same poor performance, speed and resource usage as with Firefox (try Miro Player and Joost).
The Firefox developers are literally throwing out more C code with every release, replacing it with JavaScript code.
Leaks (in the classical sense) aren't what's causing Firefox's abysmal performance, and this is why Firefox 2 performs worse than Firefox 1.5, despite one of the "features" of Firefox 2 was supposedly plenty of fixed memory leaks.
Actually I'm pretty sure they're in denial as to the cause of their problems. Announcing they're working on fixing "memory leaks" just supports their ability to continue their delusion.
Nobody forces you to use Firefox. You can use Opera, Konqueror, links or IE, or any other browser out there...
Firefox was supposed to be able to withstand popularity, unlike IE. Look at it now: people say it's slow, RAM hog, and hackers have started attacking it successfully just as much as IE.
At least we see it for what it is: the stick in Microsoft's eye that made them resume IE development.
> Actually, the big language culprits would be those with auto-garbage collection,
> etc. as they tend to have lazier programmers
Actually, it isn't lazier programmers. The problem is that existing garbage collection implementations have horrible memory profile.
If you look at the memory usage of a java program, it's about as bad as a c program that does nothing but leak memory. Practically speaking, java does little to free memory until it has *run out of memory*. Then when it does run out of memory and it needs to clean things up, things get slow as hell.
>The real answer is doing your job right, and using the right tool - which is not necessarily
>the easiest tool to use either.
Yes! Unfortunately, academics and many novice programmers (who just got finished being trained by academics) are unfamiliar with the powerful tools available like C++. Going to school can give you the mistaken impression that garbage collection is *a good thing* because everyone uses it there. The truth is that C++ is a very complicated language with a steep learning curve, but that many times it is simply the only tool that is suitable for the job.
If your program is IO bound, like a web application front end, you are in a great position, because essentially *any* tool will do the job, even if the performance is abysmal. You can use java, ruby, or whatever. And you should, becuase those languages don't present you with the complexity of c++.
Unfortunately, many programs *are not IO bound* and the performance and memory profile of the underlying tool are very important. This is most true of interactive non parializable programs. So, a good example would be bittorrent programs. Consider utorrent vs azureas, one in c++ and one in java. utorrent is fairly light weight and easy to use because of its performance characteristics. Azureus is a powerful and well engineered program, but it sure as hell is slow and chews up memory.
MOD PARENT UP.
See this +5 comment posted below: Firefox's problem is architectural and not one of garbage collection..
Quote: Actually I'm pretty sure they're in denial as to the cause of their problems. Announcing they're working on fixing "memory leaks" just supports their ability to continue their delusion. [my emphasis]
A +4 comment to that comment discusses Firefox's "four separate memory allocation schemes":
"1. Custom malloc/free implementation. (Yes, custom - not from libc.)
2. C++ new/delete operators, which for all I know may be overridden to use their malloc/free.
3. One of the first two with reference counting to decide when to free/delete.
4. JavaScript mark-and-sweep GC.
Dealing with this causes some truly insane hacks..."
Then read the comment they don't want you to see: The memory bug is also a CPU hogging bug. At present, it is marked -1 Flamebait. However, that comment begins to discuss apparent social problems at the Mozilla Foundation, and some of the same material has been marked +5 in the past.
> 1. Custom malloc/free implementation. (Yes, custom - not from libc.)
;)
Uh... No. There are some arena allocators in use in the codebase for very specific tasks, but there is no custom malloc/free.
> They're C++ objects, exposed as JavaScript objects, using something that's like XPCOM but isn't
Actually, to be exposed to JS in Gecko something more or less has to be an XPCOM object at the moment. Then the XPConnect layer handles the glue between JS and C++.
> It makes a project that's supposed to be open source effectively closed off to only the
> "official" developers
As someone who got into this project without being in any way "official", I beg to differ!