内存使用，SortedList vs List 问题答案

【问题标题】：Memory usage, SortedList vs List problem内存使用，SortedList vs List 问题
【发布时间】：2010-12-03 18:26:21
【问题描述】：

我在一个存储大约 15-100K 数据的类中使用 SortedList()。

最近我的要求发生了变化，数据不应该再按排序存储，所以我切换到 List()。

但是在这种情况下，我注意到 List() 消耗了大约 20% 以上的内存。

9K 项：

排序列表：105MB
列表：125MB

15K 项：

排序列表：115MB
列表：140MB

在我开发的环境中，记忆力非常重要。除了 List() 我可以用什么来避免这种额外的内存消耗并且仍然有一个未排序的列表？

附注我确实使用 HashSet(Of String) 来提供唯一性检查，同时使用 List(Of) 来模拟 SortedList.ContainsKey() 虽然我认为它不会带来这样的内存开销。

附注2：我的应用程序在启动时分配了大约 80 MB 的基本内存。所以数字应该读作 105-80=25、125-80 =45 等等

结果

感谢大家的回答，最终结果是：

您应该设置正确的容量以节省内存
Hashset 在内存方面非常糟糕，而且消耗的量超出预期。这就是问题所在。不知何故，SortedList() 设法为类似功能使用更少的内存。

一些基准测试： 500 个字符，250000 个插入

列表（OF 字符串）（50000）

274 毫秒 - 226 MB

SortedList(Of String, String)(50000)

34868 毫秒 - 230 Mb

哈希集

420 毫秒 - 232 MB

字典（OF 字符串，对象）

486 毫秒 - 234 MB

虽然当我将减少计数更改为 25 时，那么：

Hashset 用于 600.000 次迭代 300 Mb 其中 List() 为 286 Mb

关于 Hashset 内存使用情况：http://blog.mischel.com/2008/04/09/hashset-limitations/Dictionary(Of string, object) 在我的测试中也没有好多少。

【问题讨论】：

你从哪里得到这些值？
来自我的测试应用程序，虽然内存应该是那个内存 - 应用程序的基本内存（大约 80MB）。
来自任务管理器（或类似的）？尝试使用分析器（如 CLRProfiler：microsoft.com/downloads/…）。来自任务管理器的内存数据取决于垃圾收集行为。
我希望 List() 的内存占用大约是 "sizeof(T)" * 列表的容量（可以检查）。如果 T 是一个类，那么你只是存储引用，所以我希望，你的列表的实际占用空间是最小的（15k 个项目 * 4 个字节），也许还有其他的东西发生了变化，这对数据本身有更多的影响?
@dr. evil - 如果你抛出 uut 哈希集，只保留 List 会发生什么？ List 实际上是一个数组（正如 Martinho 所说），所以即使你为 300k 元素分配空间，它仍然只有大约 1.2MB（64 位为 2.4MB），所以列表本身不能消耗大量内存。数据或其他结构，如哈希集必须

标签： c# .net performance memory collections

【解决方案1】：

您是否正在预分配List<T> 容量？

我做过的小实验：

这个程序大约需要 640MB

List<int> list = new List<int>(0);

for (int i = 0; i < 100000000; i++)
{
    list.Add(i);
}

这个程序大约需要 320MB

List<int> list = new List<int>(100000000);

for (int i = 0; i < 100000000; i++)
{
    list.Add(i);
}

【讨论】：

+1 这是一个很好的观察结果，因为预分配的列表会在可能的情况下立即获取一个连续的 RAM 块，并减少内存碎片产生的开销。
很好，我现在就试试。 SortedList() 不存在同样的问题吗？
所有具有“容量”属性的容器都需要设置它以获得最佳性能。
我想说的这在这个比较案例中应该是无关紧要的，因为我正在比较 SortedList() 和 List() 并且没有预先分配它们。
List 也被优化为将所有内容存储在一个 continue 块中，我不知道 SortedList 是如何实现的。你必须自己检查一下。不要忘记报告结果:)

【解决方案2】：

具有 9k 个项目的 List<T> 的容量在 9k 到 18k 之间，因此这些项目的开销将在 36 到 72 KB 之间（64 位系统上的两倍）。

显然，72 kB 甚至与您看到的 20 MB 差异相差甚远，因此列表本身的内存使用不可能是原因。特别是考虑到排序列表还必须保持对每个对象的引用，所以内存使用应该是相同的。

所以，要么有其他东西在使用内存，要么您没有查看应用程序的实际内存使用情况。如果您在任务管理器中查看，您不会看到使用了多少内存，而只会看到内存管理器分配了多少。

【讨论】：

【解决方案3】：

如果您已经拥有集合的 HashSet，我不确定您为什么还需要 List，但如果您正在寻找保证唯一性和 ContainsKey() 功能的容器，为什么不使用通用字典？

无论您对上述问题做出何种决定，使用任务管理器之类的工具都太不准确，无法对 .NET 中的内存消耗做出决定。如果您还没有这样做，请试用SciTech's .NET Memory Profiler 或ANTS Profiler 并运行您的应用程序。在加载你的集合之前和在比较之后拍摄你的内存使用情况的快照。您可以使用多种集合类型执行此操作，以高度准确的方式测量每种集合的相对内存使用情况。

【讨论】：

+1 推荐使用分析器来获取准确数据。

【解决方案4】：

哈希集（和哈希表）占用大量内存！不仅仅是一个简单的列表/排序列表

【讨论】：

字典在内部使用的内存是列表的两倍（在 64 位系统上多 50%），所以差别不大。
嗯，不完全是 50%。哈希表永远不会 100% 满，当它们达到 70% 时会重新调整大小。列表只有在完全填满时才会调整大小。

【解决方案5】：

查看 Wintellect 的 Power Collections，它是 STL 类型集合的 .NET 等效项。我相信 Set 类型应该为您提供所需的功能（唯一性），但您必须进行基准比较才能进行比较。只是我的 2 美分。

【讨论】：

【解决方案6】：

我建议您查看有光泽的列表 (http://sites.google.com/site/glazedlists/)。它们的排序速度非常快，而且记忆力很好。

【讨论】：