我有一个List容器,最开始可能包含100,000个项目。当程序运行时,这个列表会慢慢清空,我应该在清空列表时改变容量吗?
我做了一些测试,执行时间似乎相同,但降低列表容量有多少开销?我可以找到很多关于增加容量的信息,但没有太多关于降低容量的信息。
答案 0 :(得分:9)
除非你的内存量非常低,否则这是微观优化。
通常,无需更改List<>
的容量。
来自TrimExcess
方法文档:
如果没有新元素添加到集合中,此方法可用于最小化集合的内存开销。但是,重新分配和复制大
List<T>
的成本可能相当大,因此如果列表容量超过90%,则TrimExcess方法不会执行任何操作。这样可以避免因相对较小的收益而产生大量的重新分配成本。
答案 1 :(得分:3)
算一算:100,000件物品*每件物品4个字节=足够400KB。如果你的程序的内存开销太大,你可以调用TrimExcess,因为Oded指出 一旦它变小了就会重新创建更小的列表。 (我不确定减少容量实际上会产生你想要的效果。)
答案 2 :(得分:2)
降低列表容量涉及新的后备阵列并复制数据,因此这是一项相对昂贵的操作。
在你的特殊情况下,我会说除非你开始遇到记忆问题,否则它是不值得的。
如果要成为一个真正的问题,可以采用的一种策略是创建IList<>
的“分块”实现,它不使用一个数组,而是多个,每个预先配置的大小,带有额外的块(已修复)大小数组)添加为前一个填充。这也允许列表通过在删除项目时释放未使用的块来相对便宜地缩小,同时将内存开销最小化为仅一个非完整块(最后一个)。
这种方法会增加列表中所有操作的性能开销,因为列表必须计算项目所在的块并根据需要创建新块。因此,除非您确实存在内存问题,并且列表确实会随着时间的推移而显着改变大小,否则它无用。