This turns into another flamewar with a lot of “my gut feeling”. Some hard data for a change (papers contain details, benchmarks, graphs, etc.):
http://www.cs.umass.edu/~emery/pubs/04-17.pdf says:
“Conclusion. The controversy over garbage collection’s performance impact has long overshadowed the software engineering benefi it provides.This paper introduces a tracing and simulation-based oracular memory manager. Using this framework, we execute a range of unaltered Java benchmarks using both garbage collection and explicit memory management. Comparing runtime, space consumption, and virtual memory footprints, we find that when space is plentiful, the runtime performance of garbage collection can be competitive with explicit memory management, and can even outperform it by up to 4%. We fi that copying garbage collection canrequire six times the physical memory as the Lea or Kingsley allocators to provide comparable performance.”
When you have enough memory, copying GC becomes faster than explicit free() – http://www.cs.ucsb.edu/~grze/papers/gc/appel87garbage.pdf
It also depends on what language you use – Java will have to do a lot of rewriting (stack, objects, generations) on each collection and writing a multithreaded GC that doesn’t have to stop the world in JVM would be a great achievement. On the other hand, you get that almost for free in Haskell where GC time will rarely be >5%, while alloc time is almost 0. It really depends what you’re doing and in what environment.