首先，有多大被认为是大的？反正是有确定多大的对象是堆？

净4.5.1带有这种 LargeObjectHeapCompactionMode ：

在所述LargeObjectHeapCompactionMode属性设置为   GCLargeObjectHeapCompactionMode.CompactOnce，下一个完整阻挡   垃圾收集（和LOH的压实）发生在一个   不确定的未来时间。您可以立即压缩蕙   使用code这样的：

  GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
 

这是我所听到的，这是一件坏事压缩蕙！因此，哪一个是最糟糕的？紧凑型LOH或有LOH不成？

分配> = 85 KB走上蕙。压实蕙也不错 - 它只是蕙碎片是不是绝大多数的应用程序需要担心，所以对他们来说是不值得压实费用

当你分配一些大对象，他们都得到来自地址空间在同一个页面出现碎片，然后让其中的一些对象得到收集。在该页面中的剩余可用空间可能无法使用，因为它太小了，甚至干脆在这个意义上被遗忘的分配永远不会考虑再次使用它。

最后，有越来越少的清洁页使用，因此分配器将开始放缓，因为它强制移动的物体，甚至开始抛出OutOfMemory异常。压实移动这些对象到新的页面，回收自由空间。

请问你的应用程序有这个对象使用模式？大多数没有。而在64位平台上，你甚至可能不会注意到它有相当多的地址空间碎片就变成一个大问题了。

First off, how big is considered large? Is there anyway to determine how large an object is in heap?

.Net 4.5.1 comes with this LargeObjectHeapCompactionMode:

After the LargeObjectHeapCompactionMode property is set to GCLargeObjectHeapCompactionMode.CompactOnce, the next full blocking garbage collection (and compaction of the LOH) occurs at an indeterminate future time. You can compact the LOH immediately by using code like the following:

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;

From what I've heard, it's a bad thing to compact LOH! So, which one is worst? Compact LOH or having LOH fragmentation?

Allocations >= 85 KB go onto the LOH. Compacting the LOH is not bad -- it's just that LOH fragmentation isn't something the great majority of apps need to worry about, so for them it's not worth the expense of compacting.

Fragmentation occurs when you allocate several large objects and they all get taken from the same page of address space, then let some of those objects get collected. The remaining free space in that page might be unusable because it is too small, or even simply "forgotten" in the sense that the allocator won't ever reconsider using it again.

Eventually there are fewer and fewer clean pages to use, so the allocator will start to slow down as it forcibly moves objects or even start throwing OutOfMemory exceptions. Compaction moves those objects to new pages, reclaiming that free space.

Does your app have this object usage pattern? Most don't. And on 64-bit platforms, you might not even notice it as there's quite a bit more address space to fragment before it becomes a huge issue.