ImmutableList<T> 的性能特点答案

【问题标题】：Performance characteristics of ImmutableList<T>ImmutableList<T> 的性能特点
【发布时间】：2014-09-06 22:03:10
【问题描述】：

它是否在某处记录了ImmutableList<T> 的性能特征？我对渐近复杂性（big-O）感兴趣。 msdn 链接没有透露太多信息。

我知道 Add 和 this[] 都是 O(log n) from this article，但我也想知道 Remove 和 Insert。

我也很想看看新引入的System.Collections.Immutable 命名空间中所有类型的复杂性是否可能。

【问题讨论】：

O 复杂度对您有何帮助？仅使用应该与您的实际用例足够接近的基准不是更简单，更有说服力吗？复杂性完全忽略了真实计算机中的大多数实际问题，并且很少会给您对生产行为的现实估计。如果您花费所有时间等待缓存未命中解决，那么算法是 O(log n) 真的对您有帮助吗？如果不考虑固定成本等，它并不是真的有用。总而言之，当您要求 big-O 时，您期望得到什么答案？
@Luaan 它在所有那些了解任何集合结构的大 O 非常有用的场景中都对我有帮助。开发人员确实需要知道它，它总是由 API 记录。对于一个实际的答案，理论知识是在成为瓶颈之前决定正确结构的经验法则。说帮我在 ImmutableList 和 ImmutableArray 之间做出选择
如果我没有事先考虑缩放，我的代码替代方案是：1）忽略该死的性能问题，只编写代码，如果情况允许，稍后再查看； 2）每次我在项目中需要时，对每一个替代方案进行基准测试——我认为这两者都很差。相反，了解复杂性是一种不错的中间方法。

标签： .net big-o asymptotic-complexity immutablelist

【解决方案1】：

好吧，根据对代码的一些检查，我预计RemoveAt（Remove 必须首先找到该项目）和Insert 与Add 几乎相同。基本原理是一样的。我更担心的是内存使用模式和类似的事情 - 如果您并排使用几个 ImmutableLists 并进行大量添加和删除，我希望您可能会很快遇到数据局部性问题，这将导致您的性能直线下降。 AddRange 主要是一个捷径，它实际上只调用了一堆Node.Adds，节省了一些开销，但不多。还有很多递归。

ImmutableArray 不会导致这种情况，因为它总是会创建一个全新的数组并复制旧数组。所以它会导致大量的内存复制和分配/收集，但它也会在性能方面更加稳定 - 访问时间不会随着使用而改变，并且在修改数组时甚至没有任何快捷方式，你总是有复制所有项目。这也意味着添加多个项目只需使用AddRange 完成 - 性能差异将是巨大的。 Add 是内部使用Insert 实现的，所以现在是一样的。也就是说，所有的change操作都是o/O(n)，而read是o/O(1)。

总而言之，ImmutableList 更关心频繁变化，牺牲读取性能，而ImmutableArray 主要用于大量读取，变化相对较少。

【讨论】：