在 .net 中分配新数组的大 O 成本

Question

.Net 中分配数组的大 O 时间复杂度是多少？

我猜如果数组足够小以适合临时段，它应该是 O(1)，但是随着 n 变大，找到足够的内存变得更加困难，因此它可能会改变。

此外，大对象堆也可能是碎片化的，因此如果 n 足够大以使数组适合 LOH，它可能不会是 O(1)。

Answer 1

一个新数组将被分配到两个不同的堆中，大多数人可能都知道，这取决于它的大小（大小阈值为 85000 字节）：

• 小对象堆 - 这里的分配发生在所谓的分配上下文中，它是内存的预置零区域，位于临时段内。这里可能会发生两种情况：
  • 在当前分配上下文中有足够的空间用于新数组 - 在这种情况下，我们可以将其视为 O(1) 操作，仅返回数组的地址（并为下一个对象碰撞指针）
  • 那里没有足够的空间 - 如果可能（就像它位于临时段的末尾），将尝试通过 分配量子（通常约为 8kB）来扩大分配上下文.在这里，我们达到了将这些 8kB 归零的成本，因此它要大得多。更糟糕的是，分配上下文可能无法扩大——因为它可能位于已分配的对象之间。在这种情况下，将创建一个新的分配上下文——在空闲列表的帮助下，在临时段内的某个地方，以利用碎片。在这种情况下，成本甚至更大——遍历空闲列表以找到合适的位置，然后将其归零。尽管如此，成本并不直接取决于数组大小并且是“恒定的”，因此我们可以像以前一样将其视为 O(1)。
• 大型对象堆 - 因为这里的分配默认频率要低得多，所以它使用“临时”分配上下文 - 每次在这里发生分配时，GC 都会在空闲列表的帮助下搜索适当的位置并将其归零.同样，空闲列表遍历和内存归零的成本都发生在这里，但由于这里的对象很大，它主要由归零成本主导。在这里我们可以谈谈 O(n) 成本。

在 LOH 分配的情况下，应该注意额外的隐藏“成本” - 在后台 GC 的某些部分期间不会发生此类分配（因为两者都在空闲列表上运行）。因此，如果碰巧有很多长的后台 GC，LOH 分配将暂停，等待 GC 结束。这显然会给您的线程带来不必要的延迟。

Answer 2

临时段（SOH；小对象堆）中的对象在该段上的最后一个已知对象之后分配。它应该只是一个指向那里的指针。

不会考虑中间的“空白”空间，因为没有空白空间。即使对象不再有引用，它仍然会在那里，直到它被垃圾收集。然后，SOH 将被压缩，因此再次没有空闲空间。

如果 SOH 不够大，则必须选择不同的 SOH，或者必须创建新的段。这需要更长的时间，但仍然是 O(1)。

LOH 有点复杂，因为它通常不会被压缩。有些网站声明 LOH 有一个“免费列表”。但我不确定它是否真的是一个列表样式的实现。我猜它有更好的管理和像字典一样工作，所以应该不会比O(log(n))差。

需要做什么？

• 可能从内核获取新内存。如果是这样，则不需要内存was already zeroed 和 memset()。
• 如果新内存在 RAM 中不可用，请先将某些内容交换到磁盘。这部分可能会变得非常昂贵但不可预测。
• 如果内存在 .NET 中已经可用，则可能需要将其初始化为零。但是memset() is optimized 的实现（例如使用rep stos）
• 用某处（例如文件）中的值初始化数组。这很可能是一个 .NET 循环，除了交换其中一个昂贵的部件。

通常，我不会考虑内存分配问题，除非您使用了可以告诉您内存吞吐量问题的分析器（如 dotMemory）。相信 Donald Knuth：“过早的优化是万恶之源”。