Game Development Reference
In-Depth Information
chapter 34
Playing Nice with the
Garbage Collector
In software, the chain isn't as strong as its weakest link; it's as weak as all
the weak links multiplied together.
Steve C McConnell
A common concern about using managed code and the .NET platform is the idea
that control over the allocation and deallocation of memory is handled by an
automated process, otherwise known as the garbage collector (GC) intrinsic to the
Common Language Runtime. Automated memory management has been around
for quite some time, most notably in the Java world, but there have been some
innovative deviations from the norm to produce a more efficient and better per-
forming garbage collector. One reason that C++ developers generally feel uneasy
making the transition from unmanaged to managed code is because they love the
control and power offered by such a low-level language and do not wish to give it
up. On the other hand, those same developers are torn because even experienced
C++ developers have to utilize patterns like smart pointers to produce reliable
The inner workings of the GC are by no means simplistic, resulting in developers
making mistakes that considerably degrade performance. Although the .NET run-
time handles a lot of the nitty gritty aspects of automated memory management,
there are some best practices that should be followed to maximize performance in
this area. This topic covers some of the proper ways to work with managed data
and the .NET garbage collector.
Search Nedrilad ::

Custom Search