On 11/11/07, Gabriel Sechan <[EMAIL PROTECTED]> wrote: > ---------------------------------------- > > Date: Sun, 11 Nov 2007 18:47:29 -0800 > > From: [EMAIL PROTECTED] > > To: [email protected] > > Subject: Still think manual memory management is a good idea? Read this ... > > > > A guy went hunting for why Firefox sucks up so much memory, and this is > > what he found: > > > > http://www.pavlov.net/blog/archives/2007/11/memory_fragment.html > > > This has nothing to do with manual vs automatic memory management. It has to > do with cache coherency and fragmentation issues. Using garbage collection > would result in no improvement, as the article explicitly states that the > data is not leaked. The real problem is doing a rather braindead allocation > method- always calling malloc to get a new block, rather than giving each > data type a pool to allocate from. Decide on a max size for each cache, > allocate it at startup, and allocate from the correct pool. You can even be > truely evil and do it automagically by overriding the new keyword. There you > do- no more out of control memory issues. When a single cache runs out of > memory, you bump old stuff from it to free up memory. Only if that doesn't > work do you malloc a bigger cache. > > If anything, a Java style automatic memory management would be FAR worse- in > C/C++, you can move to a less braindead method. In Java, the system new is > all that exists, you're stuck with it.
Don't you think the current generation of garbage collectors in Java and .NET are already making various optimizations like dead pools, generations, etc.? With Java, .NET, Python, etc someone has already spent a lot of effort figuring out how to make allocation quick and smart. With C and C++ you have to repeat this work... In those really rare cases where that's required, okay. But most desktop apps would be best done on a system with a modern garbage collector. Throw in some CPU and memory profiling work by the developer and after that, the chances that you need a custom allocator get close to zero. -Chuck -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
