Saturday, January 21, 2006

.net CLR garbage collection

While looking through our application on how to optimize it, I had several questions about the debugger, like: 1. When does the CLR decide to run the garbage collection (GC). 2. What is the size of the managed heap. How does it resize 3. What are the implications of GC on speed of the application. Found all my answers and more at these websites. The following 2 give an excellent introduction to the GC algorithm that .NET uses. (recommended read) Did you know that in tests, the CLR was quicker in allocating memory then normal win32 allocations. Apparently, the reason is that one can always be assured that when the CLR is requested for memory consecuitevely the space will be contigous and hence could all be in the CPU's memory, whereas in Win32, the memory could be fragmented and all over the place. Under the normal course of events, the GC performs periodic collections after every 1MB of allocations, the heap is compacted if it gets too fragmented, and empty segments are returned to the operating system as long as the collector’s 1 MB cache is full (this is for the .NET compact framework) Another page that is very good (this is a white paper) The following pages(blogs) have lots of in depth info about the operations of the garbage collector in .NET Using GC Efficiently – Part 1 by Maoni Using GC Efficiently – Part 2 by Maoni Using GC Efficiently – Part 3 by Maoni Using GC Efficiently – Part 4 by Maoni Using performance counters Tools for debugging memory related problems Finalization and GC

No comments: