Список против словаря (максимальный размер, количество элементов)

Question

Я пытаюсь определить максимальные размеры (в оперативной памяти) списка и словаря. Мне также любопытно, какое максимальное количество элементов / записей может содержать каждый элемент и их объем памяти на запись.

Мои причины просты: я, как и большинство программистов, несколько ленив (это добродетель). Когда я пишу программу, мне нравится писать ее один раз и стараться как можно больше ориентироваться на будущее. В настоящее время я пишу программу, которая использует списки, но заметил, что итератор хочет целое число. Поскольку возможности моей программы ограничены только доступной памятью / стилем кодирования, я хотел бы написать ее, чтобы я мог использовать List с Int64s или, возможно, BigInts (в качестве итераторов). Я видел IEnumerable как возможность здесь, но хотел бы узнать, могу ли я просто вставить Int64 в объект Dictionary в качестве ключа, вместо того, чтобы переписывать все. Если бы я мог, я хотел бы знать, какую стоимость это можно сравнить с переписыванием.

Я надеюсь, что если моя программа окажется полезной, мне понадобится всего лишь 5 лет перекомпилировать, чтобы воспользоваться увеличением памяти.

Answer 1

Указано ли это в документации к классу? Нет, тогда это не указано.

С точки зрения текущих реализаций, в самих классах нет максимального размера ОЗУ, если вы создаете тип значения размером 2 МБ, помещаете несколько тысяч в список и получаете исключение нехватки памяти, это ничего не значит делать с List<T>.

Внутренне, работа List<T> не позволит ему иметь более 2 миллиардов предметов. С Dictionary<TKey, TValue> сложнее прийти к быстрому ответу, так как расположение вещей внутри него более сложное, но на самом деле, если бы я рассматривал работу с миллиардом элементов (например, 32-битное значение, то 4 ГБ), я бы хотел сохранить их в базе данных и получить их, используя код доступа к данным.

По крайней мере, если вы имеете дело с единственной структурой данных размером 4 ГБ, переход на собственный класс сбора больше не считается изобретением колеса.

Answer 2

Я использую параллельный конкурент для ранжирования 3х3 паттернов в полмиллиона игр в го. Очевидно, что существует множество возможных моделей. В C # 4.0 конкуренту не хватает около 120 миллионов объектов. В то время он использует 8 ГБ (на компьютере 32 ГБ), но, как мне кажется, хочет расти слишком сильно (рост таблиц происходит большими порциями с одновременным предложением). Я думаю, что использование базы данных замедлило бы меня как минимум в сто раз. И этот процесс занимает уже 10 часов.

Мое решение состояло в том, чтобы использовать многофазное решение, фактически делая несколько проходов, по одному для каждого поднабора шаблонов. Как один проход для нечетных моделей и один для четных моделей. Когда больше объектов не перестает работать, я могу уменьшить количество проходов.

C # 4.5 добавляет поддержку больших 64-битных массивов, используя 32-битные указатели без знака для массивов. (упомянутый лимит составляет от 2 до 4 миллиардов). Смотрите также http://msdn.microsoft.com/en-us/library/hh285054(v=vs.110).aspx. Не уверен, какие объекты выиграют от этого, List <> может.

Answer 3

Я думаю, вам нужно решить более серьезные проблемы, прежде чем даже задаться вопросом, будет ли Dictionary с клавишей int64 полезной через 5 или 10 лет.

Наличие List или Dictionary из 2e + 10 элементов в памяти (int32) не кажется хорошей идеей, не говоря уже о 9e + 18 элементах (int64). В любом случае, фреймворк никогда не позволит вам создать монстра такого размера (даже близко) и, вероятно, никогда не позволит. (Имейте в виду, что простой массив int[int.MaxValue] уже намного превышает предел платформы для выделения памяти для любого данного объекта).

И остается вопрос: почему вы хотите, чтобы ваше приложение держало в памяти список стольких элементов? Вам лучше использовать специализированный сервер хранения данных (базу данных), если вам нужно управлять таким количеством информации.