Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Firefox Working to Fix Memory Leaks

Posted by CmdrTaco on Mon Sep 24, 2007 11:29 AM
from the important-but-boring-work dept.
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.

Related Stories

[+] Your Rights Online: Firefox 3 Antiphishing Sends Your URLs To Google 296 comments
iritant writes "As we were discussing, Gran Paradiso — the latest version of Firefox — is nearing release. Gran Paradiso includes a form of malware protection that checks every URL against a known list of sites. It does so by sending each URL to Google. In other words, if people enable this feature, they get some malware protection, and Google gets a wealth of information about which sites are popular (or, for that matter, which sites should be checked for malware). Fair deal? Not to worry — the feature is disabled by default."
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • about time! (Score:4, Insightful)

    by downix (84795) on Monday September 24, @11:32AM (#20730379)
    Too many apps nowadays just throw out RAM like it was yesterdays newspaper! It is sloppy coding, and I'm tired of having to put 2GB of RAM into a system just to surf the net nowadays.
    • Re:about time! by tritonman (Score:2) Monday September 24, @11:33AM
    • Glad the issue is getting some priority, but .... by waterbear (Score:3) Monday September 24, @11:45AM
    • Re:about time! by DustyShadow (Score:2) Monday September 24, @11:45AM
    • Because YOU allow it! (Score:4, Informative)

      by www.sorehands.com (142825) on Monday September 24, @12:10PM (#20731041)
      (http://www.barbieslapp.com/)
      It is because people accept poor programming as the norm. Oh, yeah, just reboot it and it'll be fine.

      I consult for someone who uses ACT! 2005. When they got the upgrade notice, they asked me to check it out. I spoke to ACT! support and they told me "We improved performance by releasing resources that we are no longer using." I said, "THAT IS A BUG FIX!" Anybody writing code outside of school should be doing it, and if I was grading their code, I would take points off for that.

      I'd like to see some of these software companies that do this get sued for such poor coding practices.
      [ Parent ]
    • Re:about time! by icepick72 (Score:2) Monday September 24, @01:13PM
    • Re:about time! by Threni (Score:1) Monday September 24, @01:44PM
    • Less than surprising by Anonymous Coward (Score:1) Monday September 24, @01:55PM
    • Re:C++ long-in-the-tooth? by deftcoder (Score:2) Monday September 24, @11:41AM
      • If you can't code without hand-holding tools like automatic garbage collection, perhaps you belong in a different profession!
        Professional computer programming, for example.
        [ Parent ]
      • Re:C++ long-in-the-tooth? (Score:5, Insightful)

        by SilentChris (452960) on Monday September 24, @11:49AM (#20730685)
        (http://slashdot.org/)

        If you can't code without hand-holding tools like automatic garbage collection, perhaps you belong in a different profession!


        Or perhaps they're too busy thinking about clearly-defined objects, robust interfaces, clean documentation and the "big picture" then to worry about moving individual bytes around.

        Likewise, I don't trust any artist using Flash today. They should clearly know how to code, in assembly, animation and transitions. Use of a timeline is for losers. The creative process should always be sacrificed for knowing the code inside out. /sarcasmoff
        [ Parent ]
        • Re:C++ long-in-the-tooth? (Score:4, Insightful)

          by caerwyn (38056) on Monday September 24, @11:56AM (#20730797)
          Or perhaps they're too busy thinking about clearly-defined objects, robust interfaces, clean documentation and the "big picture" then to worry about moving individual bytes around.

          Actually, I'd say they're not busy enough- if they actually had been, proper memory management should simply fall into place on top of a clean architecture. If you're trying to shoehorn memory management back into something that didn't support it before, you're going to have issues- and this applies whether you're doing c/c++ style management, reference counting, or garbage collecting.
          [ Parent ]
        • Re:C++ long-in-the-tooth? (Score:5, Insightful)

          by Kristoph (242780) on Monday September 24, @12:00PM (#20730883)
          A computer, by definition, 'moves bytes around'. One might argue that this is the job of the computer (or language or VM or whatever) and not programmer but if you don't understand how / why and when the bytes are moved around then you are a poorer programmer for it.

          C++ yields superior performance and memory usage, than higher level languages, in the hands of a skilled C++ programmer and it can lead to bloatware in the hands of a novice.

          There is this old saying about blaming your tools for a poor job and it applies to software development too.

          ]{

          [ Parent ]
          • Re:C++ long-in-the-tooth? (Score:4, Insightful)

            by dgatwood (11270) on Monday September 24, @01:49PM (#20732643)

            Precisely. A skilled craftsman does not blame the tools. A skilled craftsman does the job right, and if it cannot be done right with the tools at hand, he/she goes and gets tools that are appropriate for the job.

            Poor programming is possible in any language, and garbage-collected languages are no exception. I would also caution that garbage-collected languages tend to encourage more novice programmers because of the apparent ease of use (it isn't really easier). This results in a larger number of poorly-written apps by people who think they know how to write software. Taking away the need to explicitly manage memory just encourages lazy programmers who can always find something else to be sloppy about.

            As for garbage collection making this sort of thing magically go away, that simply isn't the case. Working around garbage collection with things like "soft references" is a disgusting hack and is actually far harder than simply doing explicit memory management in the first place. Anyone who says differently has never had to manage any complex data structures that reference each other in non-trivial ways. The alternative is to basically write your own code that explicitly walks the data structure, deleting circular references, etc. If you're going to that much trouble, you are doing just as much work as you would for explicit memory management, but without the performance benefits from actually being able to destroy the objects immediately, and thus garbage collection is just hurting performance without providing any real benefit.

            Basically, apart from the really trivial cases (most of which could be solved just as easily by simply creating a stack-local auto-destroy variant of malloc), garbage collection causes more problems than it solves. In my book, garbage collection in programming language ranks right up there with multiple inheritance as one of the worst ideas ever conceived.

            [ Parent ]
          • Re:C++ long-in-the-tooth? by Wavicle (Score:2) Monday September 24, @01:54PM
          • Re:C++ long-in-the-tooth? by Anonymous Coward (Score:1) Monday September 24, @02:48PM
          • Re:C++ long-in-the-tooth? by owlstead (Score:2) Monday September 24, @05:07PM
        • Re:C++ long-in-the-tooth? by gcauthon (Score:2) Monday September 24, @12:01PM
        • Re:C++ long-in-the-tooth? (Score:5, Insightful)

          by Hatta (162192) on Monday September 24, @12:26PM (#20731293)
          (Last Journal: Monday November 28 2005, @12:21PM)
          Likewise, I don't trust any artist using Flash today.

          That's a good instinct. Never trust anyone using Flash.
          [ Parent ]
        • 1 reply beneath your current threshold.
      • Re:C++ long-in-the-tooth? (Score:5, Interesting)

        by suv4x4 (956391) on Monday September 24, @11:50AM (#20730691)
        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.

        [ Parent ]
        • Mod parent up (Score:5, Insightful)

          by Anonymous Coward on Monday September 24, @12:14PM (#20731111)
          The parent post is completely correct. The main problem with Firefox and Mozilla in general is the XUL architecture. It is single-threaded such that JavaScript cannot run in multiple threads. And I've tried. It can't be done, Firefox will actually crash. (You can try with XPCOM, but it will crash.) I asked, and the solution given to me by the Firefox community (which isn't necessarily the developers, mind you) was to use Java from JavaScript, which is a non-starter if you want to write a cross-platform extension. (Not because Java isn't crossplatform, but because you can't guarantee that Firefox will be installed with a JVM.)

          Firefox's problem is architectural and not one of garbage collection.
          Unfortunately part of their problem is garbage collection - it's due to their architecture, but they have at least four separate memory allocation schemes going:

          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, like the absolutely insane DOM C++/JavaScript implementation. (They're C++ objects, exposed as JavaScript objects, using something that's like XPCOM but isn't due to the overhead XPCOM imposes. I really don't understand it.)

          Ultimately, though, it's worse than all that. All this crap leaves the code completely opaque, and actively prevents contributors from contributing code without having to learn an insane amount of infrastructure decisions.

          It makes a project that's supposed to be open source effectively closed off to only the "official" developers: almost open source in name only.
          [ Parent ]
          • Re:Mod parent up by Dr. Spork (Score:2) Monday September 24, @01:42PM
          • Re:Mod parent up (Score:5, Interesting)

            by BZ (40346) on Monday September 24, @01:59PM (#20732805)
            (http://web.mit.edu/bzbarsky/www/)
            > 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! ;)
            [ Parent ]
          • Re:Mod parent up by sjames (Score:2) Tuesday September 25, @11:38AM
          • Re:Javascript engine Tamarin will use conservative by QuoteMstr (Score:2) Tuesday September 25, @01:59AM
          • 2 replies beneath your current threshold.
        • Re:C++ long-in-the-tooth? (Score:5, Informative)

          by jsebrech (525647) on Monday September 24, @12:15PM (#20731131)
          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). ...

          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.


          They're not in denial. They're working on tamarin [mozilla.org], a replacement/upgrade of their javascript engine based on the same engine that's in flash 9 / actionscript 3.

          Tamarin will run javascript 2, which will to do javascript what the move from actionscript 2 to 3 did for flash/flex. In short: it will make non-toy applications easily done, instead of just marginally feasible. They plan to migrate the firefox UI and extensions to javascript 2, which should negate the performance issues. Only problem: it won't be ready for FF3.
          [ Parent ]
      • Re:C++ long-in-the-tooth? by SheldonYoung (Score:2) Monday September 24, @11:51AM
        • Re:C++ long-in-the-tooth? by Kristoph (Score:2) Monday September 24, @12:06PM
        • Re:C++ long-in-the-tooth? (Score:5, Insightful)

          by i7dude (473077) on Monday September 24, @12:09PM (#20731011)

          Your argument is nonsense. If what you said held true, large scale applications should be able to be written is assembler. Without high level tools it wouldn't be feasible to create applications the scale we do today.


          Wrong. What he is saying is that people who choose to use C/C++ for their applications should be competent enough to properly handle their own allocation and de-allocation of memory. If your abilities as a programmer preclude you from properly managing your application's memory then you need to look at alternatives that will take care of that for you.

          There are plenty of languages out there that offer things like garbage collection. Developers need to make better choices about which tools they use to meet their needs, and also understand their limitations and work within those parameters.

          dude.
          [ Parent ]
      • Re:C++ long-in-the-tooth? by TuringTest (Score:2) Monday September 24, @11:54AM
      • Re:C++ long-in-the-tooth? by Rei (Score:2) Monday September 24, @11:54AM
      • Re:C++ long-in-the-tooth? by Tablizer (Score:1) Monday September 24, @12:14PM
      • Re:C++ long-in-the-tooth? (Score:4, Insightful)

        by ultranova (717540) on Monday September 24, @12:17PM (#20731165)

        If you can't code without hand-holding tools like automatic garbage collection, perhaps you belong in a different profession!

        Statements like this are why I prefer Java programs to C ones. Mandatory bounds checking means that no macho idiot can turn it off, no matter how full of hubris he is. But even assuming a 100% perfect coder, does it really make sense to use his precious time to worry about memory management when the computer can do that automagically ?

        [ Parent ]
        • Re:C++ long-in-the-tooth? by maxwell demon (Score:1) Monday September 24, @02:34PM
        • Re:C++ long-in-the-tooth? (Score:4, Insightful)

          by Wavicle (181176) on Monday September 24, @02:37PM (#20733391)
          You realize, of course, you are seriously going against Slashdot groupthink here. Still, if I had mod points, I'd give you one. Macho programmers who think they are too awesomely skillful to screw up are the ones whose screwups always take me the most time to chase down.

          Frankly if you can't look at a problem and then pull out five or six languages from your tool belt and evaluate which will be the best for this job, then you are a bad programmer. Don't code in C++ that which could easily be done in Python. Don't code in Python that which could easily be done in Bash. If you don't have a compelling argument for using C, DON'T USE IT!

          Sometimes I think Java is awful for no other reason than companies tend to believe that using one language for other is a net gain. That has never been my experience except when your very best programmers aren't all that good either. If you insist that everything run on the Java runtime, use Jython and embed Python. A good example of multi-language gains can be seen with embedded Lua. There are many applications out there that use Lua "under the covers" so that things that do not have to be written in C++ aren't. This includes games (I believe WoW is one).
          [ Parent ]
          • Re:C++ long-in-the-tooth? (Score:4, Insightful)

            by plover (150551) * on Monday September 24, @04:28PM (#20734995)
            (http://slashdot.org/ | Last Journal: Thursday April 12 2007, @09:41AM)

            Frankly if you can't look at a problem and then pull out five or six languages from your tool belt and evaluate which will be the best for this job, then you are a bad programmer.

            While I agree with this sentiment on principle, in practice this has proven to yield unworkable solutions. Different people bring different skillsets to the table. You may have a dozen developers who all have C++ in common, but to varying degrees. One may be more skilled in Perl, another in smalltalk, another in Python, and three more in Java. Divvy up the specs and tell each one to "Write your code using the best tool for the job." Then spend another year trying to integrate the pieces, and when they quit try to hire someone who can maintain the hydra.

            Picking a single language for a project (at least at the component level) is pretty much a requirement.

            Even though they try to hand-wave it away, this has been a big problem in the Microsoft .NET world. When it was introduced, Microsoft promised that all .NET languages were equal, first-class languages (my interpretation at the time was that C# programmers were instantly demoted to VB programmers :-( ) and that a developer could write in whichever .NET language they were most comfortable. But there are C# programmers and VB.NET programmers who don't really speak each other's language, even though they all compile down to the same MSIL. Trying to get them to maintain each others code leads to a lot of squabbling.

            It's easy to say "A good programmer can write in any of these languages" but in reality it's much harder to find a lot of good programmers that are both willing and able to competently do maintenance in all of the languages you might end up with.

            [ Parent ]
        • Re:C++ long-in-the-tooth? by Nicolay77 (Score:2) Monday September 24, @07:03PM
        • Re:C++ long-in-the-tooth? by sjames (Score:2) Tuesday September 25, @03:33PM
      • Re:C++ long-in-the-tooth? by JackMeyhoff (Score:1) Monday September 24, @01:33PM
      • Re:C++ long-in-the-tooth? by plague3106 (Score:1) Monday September 24, @02:21PM
      • Re:C++ long-in-the-tooth? by RazzleDazzle (Score:2) Monday September 24, @03:45PM
      • Re:C++ long-in-the-tooth? by HeroreV (Score:2) Monday September 24, @08:01PM
      • Re:C++ long-in-the-tooth? by AVee (Score:2) Tuesday September 25, @04:12AM
      • Re:C++ long-in-the-tooth? by Paradox (Score:2) Tuesday September 25, @05:51PM
      • 1 reply beneath your current threshold.
    • Re:about time! by MightyMartian (Score:2) Monday September 24, @11:49AM
    • Re:C++ long-in-the-tooth? (Score:5, Insightful)

      Perhaps the culprit is C++. Languages with auto-garbage-collection or are database-engine-based tend to clean up automatically or cache to disk more effectively.
      Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources, and in some cases even prohibit the programmer from being able to manage their resources.

      C/C++ and similar languages, on the other hand, force the programmers to manage their resources. In those cases, the programmers would likely be just not designing their programs well, or employing bad resource management. Yes, managing resources can be hard - one project I worked on had to go through several months of testing to get the resources properly managed, and even then some of the resources were still a little uncontrollable due to legacy code or Windows APIs, but overall the thing was pretty stable and any memory leaks were mostly due to Windows APIs.

      In either case, I can't tell you how many times I have heard (especially from Java programmers) something along the lines of the following: "RAM is cheap", "processors are getting faster", "computers will be ready for this when we deliver it", "hardware is cheaper than programmers"

      No offense, but to rely on hardware always being getting faster, or the cost of adding more RAM always being cheaper, etc. is a bad premise to rely on. Already with multi-core processors we are seeing slower processors being combined into a single processor get the equivalent processing power of a faster processor (e.g. two 1.8 Ghz cores rated equally to a single 3 Ghz core); thus the premise breaks down. Also, I want to be able to do more with the faster processors and additional RAM, rather than simply do the same job I could do yesterday only in "better" software.

      The real answer is doing your job right, and using the right tool - which is not necessarily the easiest tool to use either. We also need to get back to writing applications that have good, if not great, performance with minimal resource requirements (e.g. RAM and processor). If we're not going this at the API/library level - at the very least - then the programs and library/APIs that rely on that API/library level will have worse performance no matter what they do. But in either case it doesn't get done unless the programmers do their job, and use tools that allow them to do it.
      [ Parent ]
      • Re:C++ long-in-the-tooth? by Oswald (Score:2) Monday September 24, @12:07PM
      • Re:C++ long-in-the-tooth? by Rei (Score:2) Monday September 24, @12:10PM
      • Re:C++ long-in-the-tooth? (Score:4, Insightful)

        I am not sure where you think C++ Programmers are more careful the Other Higher language programmers. A lot of C++ Programmers are really not that good the only reason they use C++ because they had to take it part of their college requirements, thus being the only language they know. Problem with C++ is the fact programming memory is so intensive that most people will be willing to let it leak because of all the extra work it will take to clean it up. They program in C++ not because it is the best tool for the job but the one they know the best. I have seen cases where C++ Project get killed because they take way to long to write and more to debug, while Python, VB or Java Programmers seem to get the job done. Most projects are not Open Source, Most programming is actually just custom program for businesses so these programmers are paid by the hour.

        I Agree with you the Duel Cores are not equal to systems with twice the GigaHertz and the singlecore twice as fast system normally will out preform the application written. But that isn't about C++ Program or Java Programming, It is about Multi-Threaded programming. Parallel processing is a different form of programming that most programmers shy away from. But still the fact if you are paying a programmer $20 and hour and it takes them twice as long to get a 10% increase in speed it would be better off buying extra RAM then paying the programmer.

        Now if you are getting a boxed application that is different because the cost of application development programming is spread across all the people who buy it. So by Doubling the price of the Shrink Wrapped App. say from $80 to $160 and everyone gets a 10% increase in speed then it is worth it to put the extra in and get it more optimized, the degree of benefit will outweigh the costs.

        The thing that usually gets me like comments like this parent it assumes a completely Academic Computer Science approach to all problems. While real life requires making trade offs and sacrificing performance is often a good trade off to make because most of the time it is unnoticeable, most computers spend most of their time idle anyways, and most application are idle waiting for inputs. So in the once in a while heavy processing moment say in this case an HTML Render adding 1 second to the load in real life most people wont notice unless they are going back and forward button crazy. Or doing a batch rendering job. As for memory I am surprised that you didn't bring up the large quanity of 32bit systems still out there being sold as new only handling a max of 4 GB or RAM so for a large population RAM limits are an issue again.
        [ Parent ]
      • Re:C++ long-in-the-tooth? by Anonymous Coward (Score:1) Monday September 24, @12:51PM
      • Re:C++ long-in-the-tooth? by Tibixe (Score:1) Monday September 24, @12:58PM
      • Re:C++ long-in-the-tooth? by Doctor Crumb (Score:3) Monday September 24, @01:06PM
      • Re:C++ long-in-the-tooth? by flyingfsck (Score:2) Monday September 24, @01:10PM
      • Re:C++ long-in-the-tooth? by Anonymous Coward (Score:1) Monday September 24, @01:11PM
      • Re:C++ long-in-the-tooth? by edxwelch (Score:1) Monday September 24, @01:11PM
      • Re:C++ long-in-the-tooth? by dhasenan (Score:2) Monday September 24, @01:18PM
      • java memory profile (Score:5, Interesting)

        by sentientbrendan (316150) on Monday September 24, @01:33PM (#20732285)
        (Last Journal: Monday February 03 2003, @08:59PM)
        > 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.
        [ Parent ]
      • Re:C++ long-in-the-tooth? by e2d2 (Score:2) Monday September 24, @01:47PM
      • Re:C++ long-in-the-tooth? by fwarren (Score:2) Monday September 24, @01:59PM
      • Re:C++ long-in-the-tooth? by naasking (Score:2) Monday September 24, @05:24PM
      • Re:C++ long-in-the-tooth? OMG by talledega500 (Score:1) Monday September 24, @11:20PM
      • Re:C++ long-in-the-tooth? by Walles (Score:2) Tuesday September 25, @09:44AM
      • 1 reply beneath your current threshold.
    • Re:C++ long-in-the-tooth? by Yahma (Score:1) Monday September 24, @11:58AM
    • Re:C++ long-in-the-tooth? (Score:4, Informative)

      by Constantine XVI (880691) <trash DOT eighty AT gmail DOT com> on Monday September 24, @12:10PM (#20731037)
      Sorry, but quite a few other browsers (Opera, Konqueror, Safari(the WebKit part anyways)) are written in C++, and they don't seem to have near the problems Firefox has.
      [ Parent ]
    • Re:C++ long-in-the-tooth? by nwf (Score:2) Monday September 24, @12:44PM
    • Automatically != Efficiently (Score:5, Informative)

      by ClosedSource (238333) on Monday September 24, @01:23PM (#20732153)
      A well-written C++ program is going to free memory much faster than a GC can. The value of GC is that you don't have to worry about forgetting to free memory, it will happen - eventually.
      [ Parent ]
    • Memory leaks by Per Abrahamsen (Score:3) Monday September 24, @01:25PM
    • Re:C++ long-in-the-tooth? by Dancindan84 (Score:1) Monday September 24, @01:25PM
    • Re:C++ long-in-the-tooth? by dgatwood (Score:1) Monday September 24, @02:18PM
      • 1 reply beneath your current threshold.
    • C++ was broken for Garbage Collection from day 1. by Ungrounded Lightning (Score:3) Monday September 24, @04:47PM
    • Mod Squad - Re:C++ long-in-the-tooth? by Tablizer (Score:1) Monday September 24, @10:24PM
    • 3 replies beneath your current threshold.
  • Bloat in general (Score:5, Insightful)

    by pipatron (966506) <pipatron@gmail.com> on Monday September 24, @11:32AM (#20730385)
    (http://www.vhemt.org/)
    I don't mind the memory. I have plenty of gigs even in my laptop. What I mind is the general slowness that I experience with Firefox, and that makes me use Opera on my laptop even though I would feel better using an open source browser.
  • Yay! (Score:1)

    by benmatth (1160859) on Monday September 24, @11:32AM (#20730393)
    This is what has been keeping me off Firefox on my memory-lacking iBook.
    • Re:Yay! by Generic Guy (Score:1) Monday September 24, @11:48AM
    • Re:Yay! by Mr. Underbridge (Score:2) Monday September 24, @12:16PM
  • but but (Score:5, Interesting)

    by svendsen (1029716) on Monday September 24, @11:33AM (#20730399)
    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
    • Re:but but by onetwentyone (Score:2) Monday September 24, @11:42AM
    • Re:but but by Martin Blank (Score:2) Monday September 24, @11:46AM
    • Re:but but (Score:5, Interesting)

      I've heard that too. I use FF on my desktop at work with one or two plugins (FlashBlock and FireBug, mostly). It does leak memory after enough time. Closing the browser always fixes it, so it's not much of a problem.

      That said, if a plugin leaks memory, there are a few options. First, the system should know. Even if the plugin in used constantly, I should be able to open the extensions options panel and see how much memory each one is using, so I can identify the culprit. There should be a warning system ("Plug-in 'MemHog2' is using 500MB of ram, close/ignore/disable?").

      Also, when a plugin isn't in use, then it shouldn't cause a problem. Let's say that the problem is Flashblock. If it isn't actively rendering (say I only have one window/tab open and it's pure text, no flash/etc) then it really shouldn't be using any memory. If I have FireBug inactive it should use next to no memory (when I have it actively checked CSS/JS/etc I expect it to use memory).

      I'm glad they are working on this. I've heard this complaint for a while. But even if the problem is the plugins, it needs fixing or roping in.

      How about being able to set memory limits for plug-ins, Mac OS 1-9.x style? Maybe total, maybe per active page, maybe both. Just a random idea.

      [ Parent ]