Languages with garbage collection have no need of a free or delete operator, because unused heap memory gets reclaimed automatically by the language runtime. This reduces the complexity of source code, eliminates the need of keeping reference counts for shared objects, and prevents most memory allocation bugs and all memory leaks.
Over the years, garbage collection has gained a reputation for inefficiency. A large, object-oriented LISP program performed terribly compared to hand coded, micro-optimized assembly, and a good portion of the blame was placed on garbage collection.
Times have changed, however. Garbage collection technology has improved. Processors speed has increased enormously. Most importantly, however, the standard practice of the industry has changed, and large commerical software is now built in C++.
No good benchmarks exist for the relative performance of large C++ systems (greater than 15 thousand lines of code or so), and similar systems designed from the ground up to use garbage collection. The benchmarks which do exist typically test the performance of relatively small pieces of code—small enough that one programmer can optimize the overall usage of memory—or have compared a good system without garbage collection to a direct reimplementation of that system using a garbage collector. Overall, no one seems to know just how fast GC is, relative to a typical large C++ program. It is known, however, that good GC code uses different designs than non-GC code, and often spends less time needlessly copying data.