列表与字典(最大大小、元素数)

本文关键字:元素 列表 字典 | 更新日期: 2023-09-27 18:20:44

我正在尝试确定List和Dictionary的最大大小(在RAM中)。我还想知道每个元素/条目可以容纳的最大数量,以及每个条目的内存占用量。

我的理由很简单:我和大多数程序员一样,有点懒惰(这是一种美德)。当我写一个程序时,我喜欢写一次,并尽可能地经得起未来的考验。我目前正在编写一个使用Lists的程序,但注意到迭代器需要一个整数。由于我的程序的功能仅受可用内存/编码风格的限制,我想写它,这样我就可以使用Int64s或BigInts的List(作为迭代器)。我在这里看到了IEnumerable的可能性,但我想知道是否可以将Int64作为关键字插入Dictionary对象,而不是重写所有内容。如果可以的话,我想知道与重写它相比,它的成本是多少

我希望,如果我的程序被证明是有用的,我只需要在5年内重新编译,就可以利用内存的增加。

列表与字典(最大大小、元素数)

是否在类的文档中指定?不,那就没有具体说明。

就当前的实现而言,类本身的RAM没有最大大小,如果您创建一个大小为2MB的值类型,将几千个值推入列表,并接收到内存不足异常,那么这与List<T>无关。

在内部,List<T>的工作方式将阻止其拥有超过20亿个项目。使用Dictionary<TKey, TValue>很难快速找到答案,因为事物在其中的定位方式更复杂,但实际上,如果我想处理10亿个项目(例如,如果是32位值,那么是4GB),我会希望将它们存储在数据库中,并使用数据访问代码检索它们。

至少,一旦您处理了4GB大小的单个数据结构,推出自己的自定义集合类就不再算是重新发明轮子了。

我正在使用concurrentdictionary对50万场围棋游戏中的3x3模式进行排名。显然有很多可能的模式。在C#4.0中,concurrentdictionary在大约1.2亿个对象处内存不足。当时它使用的是8GB(在32GB的机器上),但我认为它想增长太多(使用concurrentdictionary时,表会大量增长)。我想,使用数据库至少会让我慢一百倍。这个过程已经花了10个小时。

我的解决方案是使用多阶段解决方案,实际上进行多次传递,每个模式子集一次。就像奇数模式和偶数模式的一次通行证。当使用更多对象不再失败时,我可以减少过程的数量。

C#4.5通过对数组使用无符号32位指针,增加了对64位较大数组的支持(上述限额从20亿增加到40亿)。另请参阅http://msdn.microsoft.com/en-us/library/hh285054(v=vs.110).aspx。不确定哪些对象将从中受益,请列出<>可以

我认为,在想知道带int64密钥的Dictionary在5年或10年后是否有用之前,您还有更大的问题需要解决。

在存储器中拥有2e+10个元素的ListDictionaryint32)似乎不是一个好主意,更不用说9e+18个元素(int64)了。无论如何,这个框架永远不会允许你创建一个那么大的怪物(甚至不接近),而且可能永远不会。(请记住,一个简单的int[int.MaxValue]数组已经远远超过了框架对任何给定对象的内存分配限制)。

问题仍然存在:为什么你希望你的应用程序在内存中保存一个包含这么多项目的列表?如果必须管理这么多信息,最好使用专门的数据存储后端(数据库)。