Even the best garbage collection algorithm(s) can not beat a well
informed programmer.
Perhaps, but the trick there is the term "well informed". In more
complex systems where objects (pointers) are passed between all sorts of
layers of execution (not to mention threads) you simply can't be (and
don't want to be) well-informed about the inner workings of all those
layers.
There are other advantages that non-GC based memory management does not
provide. These include moving the memory management functions (at least
the deallocation part) into another thread so the main threads aren't
impacted by its performance. Knowledge of OS memory pressure so it won't
bother with collection if there's no need. Knowledge of
locality-of-reference and the ability to rearrange memory, even when
it's in use, to put objects referenced together in memory together to
take better advantage of L2 and L3 cache. And knowledge of NUMA and
which processor(s) a given task is executing on so it can move the
memory for those tasks "closer" to those processors.
Could a programmer keep track of all this? Sure. After all, it took a
programmer to write the GC code in the first place. However, we're
application developers, I don't want to understand the finer points of
Non-Uniform-Memory-Access in a 16-way machine made up of 4 clusters of 4
cpus to better allocate my memory access. But I do love the fact that I
get a performance kick from it.
-Walden
midrange.com
