On Tue, 21 Apr 2009 16:57:33 +0200, joaquin@tid.es wrote:
The point is that deferring memory release to the next GC round can be faster than releasing every little piece of memory immediately, at least in some scenarios:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/#details
Take into acount that free(x) is by no means free in terms of execution time (no pun intended) --some bookkeeping has to be done by the internal memory manager when freeing a block of memory.
A decent memory allocator avoids actually freeing memory when you call free/delete. Instead, the block will be marked as available and future memory allocation may use this block (if it fits). This operation is inexpensive. Depending on your memory constraints, actual deallocation may even never happen (see STLPort default allocator). Memory pool can go further and be even more efficient because all blocks have the same size, making reusing very easy and efficient. Garbage collector just displace the memory management problem. Large applications still need careful design. No silver bullet. I'm very doubtful about the benefits of a C++ garbage collector but I'd be very happy to be proven wrong. -- EA