Garbage Collection and Optimization
As you might imagine, garbage collection itself is a computationally expensive process. It has the advantage of significantly improving the speed of memory allocations over unmanaged languages, because it simply allocates a block at the top of the heap and moves the heap pointer to the next free memory address. However, the garbage collection process potentially rescinds that advantage during memory reclamation. Tracing object references, then compacting memory, takes significantly more time than manually freeing memory back onto the heap.
It gets worse. Multi-threaded applications add to the complexity of garbage collection. When the garbage collector starts reclaiming memory, it gathers free objects as well as moves pointers on the heap. When memory requests by one thread initiate a garbage collection, the other threads can’t access any other object. In effect, the entire application stops while garbage collection is occurring. The garbage collector uses a few different mechanisms to suspend threads safely so it can perform a collection. The reason for the multiple mechanisms is to keep threads running as long as possible and to reduce overhead as much as possible. Microsoft has implemented these measures that enable the .NET Framework to improve thread-execution efficiency in order to minimize downtime due to garbage collection and improve performance, but this still represents a complete stop of the application.
This doesn’t mean, however, that you should avoid managed code to achieve high performance. The performance improvements in memory allocations, coupled with the elimination of traditional native code memory management errors, are more than enough reason to take advantage of managed applications. But it’s essential to use the .NET Framework with a good understanding of how the garbage collector works and how you can use memory management strategies to improve the performance of your applications.
As you might imagine, the automatic memory management used by the .NET Framework and CLR dramatically changes the art of application development. In the past, application development had involved processing data by moving it among different memory locations by manipulating pointers to that data in memory. Today, application development means processing data by creating and customizing objects and using methods to act on the data represented by those objects. The act of manipulating that data in memory, though very real, is indirect and in many ways hidden from the developer.
This means that developers still have to worry about memory management. But the rules have changed. Rather than concentrating on the tactical mechanics of allocating, initializing, casting and freeing memory blocks of specific size and location, developers can focus on overarching strategies for using memory management to improve application performance and reliability.
Memory Management Gone Bad
The activities of the garbage collector seem relatively straightforward and well thought-out. Details will likely change in subsequent releases of the .NET Framework, based on experience gained by Microsoft in the behaviors of actual applications, along with incremental improvements in technology. But many problems can arise in the details. Minor implementation changes in the same application can result in substantial performance differences. A few seemingly innocuous constructs can greatly slow down an application, or cause it to "leak" objects (keep them around after they are no longer in use). Following are a few of the more significant issues brought about by the garbage collector’s strategy that could negatively impact an applications execution.
