.NET 4.5 memory and performance improvement simplified

Zahid Hossain C# ,
Most of all probably already know about this. Certainly upgrading to .net 4.5 should be on the road map at some point since it has tremendous improvement on garbage collection algorithm and memory fragmentation on Large object heap. Therefore it might solve some of our memory problem such as too much memory usage, OutOfMemoryException, Overly fragmented heap as well as excessive CPU usage without sacrificing latency. As we know, if object is over 85,000 bytes it goes it large object heap (LOH) and smaller than that goes to small object heap (SOH).  During cleanup process for all generations (including LOH), garbage collector compacts SOH for all non-garbage objects and put it together so that next time it gets enough space to allocate object and no fragmentation issues there as per their implementation of mark-sweep-compact algorithm.
However, Issues are with Large Object Heap (LOH). During cleanup process garbage collector does not compact (see red circle). Reason is it has performance hit due to upgrading all the pointers of the new heap location. BUT, before .net 4.5, if CLR wants to allocate an object in the red circle area and if it is too small, it will allocate somewhere else and CLR will NEVER come back to red circle to allocate any other object. That space is totally wasted for the lifetime of the process as per their algorithm. Over the time, we will have overly fragmented heap with high memory consumption and out of memory exception.
Inline image 3
In .NET 4.5, along with other benefits, algorithm improved, it will keep trying to allocate object in that area (any empty space). On top of that we can manually COMPACT the Large Object Heap (LOH) just like SOH using “GCSettings.LargeObjectHeapCompactionMode” in a separate thread and therefore no more fragmentation issues, less memory usage, possibly no out of memory exception (unless it has memory LEAK).
Not to mention, .NET also has start-up improvement which is very much needed for applications with heavy winform and wpf.  It uses multi-core JIT compilation if the pc has multicore. How? Compiler saves the JIT list of calls in a file for the very first time it runs, next time it reads from the file and start to jit in advance in another core knowing let’s say method C will be called from B followed by A, JIT compiler knows this sequence in advance from that file.
Anyway, just thought of sharing it. If you like it please leave a comment or discuss or correct me anything you do not agree.