This is a great question.
Most C/C++ programmers have an urge to call the garbage collector as soon as possible (just like you are suggesting). However, there have been numerous studies that this almost always makes the program run slower than if the garbage collector is left to run when it decides it is ready.
Why does this happen?
Well, when a garbage collection takes place, all of the good objects are copied away in a new area, and then the old object area is thrown away. This is a good strategy if the number of good objects is small relative to the total number of objects that have been created. And study after study has shown that this is almost always true.
So, what this means is that the longer you can wait between garbage collections, the greater the percentage of total data that can be thrown away. Hence, as the time between garbage collections goes to infinity, the cost of reclaiming storage steadily shrinks to zero. Note that in the limit, garbage collection is thus provably faster than using malloc/free in C programs. In practice, if one can accept an overhead of about 10-to-1 in total heap size to size of live data, then the cost of memory management in a garbage-collected system is better than using malloc/free in C.
The bottom line: Every garbage collector waits as long as possible before running. And every scheme that has been tried to run the garbage collector more often results in longer running times in the majority of cases.
Now, of course there will be specific programs where calling the garbage collector early will be a big win. But this is the rare case, not the common case. |