9

最近我正在运行Andrew Hunter 在他的博客“大对象堆的危险”中提供的示例，该示例针对 .NET 4 编译，我得到了以下数字：

大块：分配 622Mb
大块，频繁垃圾收集：分配 582Mb
仅小块：分配 1803Mb
大块，未增长的大块：分配 630Mb

如果针对 .NET 2.0 编译相同的代码，我几乎得到了文章中提到的数字：

使用大块：分配 21Mb
使用大块，频繁垃圾收集：分配 26Mb
仅分配小块：分配 1811Mb
使用大块，未增长的大块：分配 707Mb

如此显着改善的原因是什么？

代码针对 x86 平台编译并在 Windows 7 上运行

4

3 回答 3

4

CLR 团队的一些急需工作是改进的原因，但显然仍有改进的余地：

http://mitch-wheat.blogspot.com/2010/11/net-clr-large-object-heap.html

于 2011-03-23T23:41:52.033 回答
4

发生了一些变化，但这是一个保守的秘密，我找不到任何关于它的信息。我不会投入太多的股票。代码示例经过手动调整，以使 CLR 2 大对象堆看起来尽可能糟糕。即使是受到博文启发的算法的微小变化，也会产生非常大的影响。

于 2011-03-24T00:12:05.217 回答
2

我可以想到微软可以对内存分配器做的一些简单的事情，这些事情可以在没有大修的情况下大大减少 LOH 碎片，例如将分配大小四舍五入到 4K 之类的倍数。鉴于最小的非静态 LOH 对象为 85K，这最多会损失 5% 的有用空间，但会减少不同大小的对象和间隙的数量。顺便说一句，我真的不相信将所有大对象强制到 LOH 的价值（也许，有一种方法可以指定何时创建对象是否应该进入 LOH）。我可以理解，一旦它们达到 2 级，将小对象与大对象区分开来的一些价值，但是有足够多的情况下，大对象被创建和放弃，迫使它们进入 2 级似​​乎适得其反。

于 2011-03-24T03:33:20.727 回答