Практические пределы размера Hashtable и словаря в c #

Каковы практические ограничения на количество элементов, которые может содержать C # 4 Dictionary или Hashtable, и общее количество байтов, которые могут содержать эти структуры. Я буду работать с большим количеством объектов и хочу знать, когда эти структуры начнут испытывать проблемы.

Для контекста я буду использовать 64-битную систему с тоннами памяти. Кроме того, мне нужно найти объекты, используя некоторую форму или «ключ». Учитывая требования к производительности, эти объекты должны будут находиться в памяти, и многие из них будут долгоживущими.

Не стесняйтесь предлагать другие подходы / шаблоны, хотя мне нужно избегать использования сторонних библиотек или библиотек с открытым исходным кодом. По причинам спецификации, я должен быть в состоянии построить это, используя родной C # ( или C ++ \ CLI ).

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

Я собрал несколько тысяч элементов в Словаре в памяти, и проблема заключается не в размере Словаря, а в размере самих объектов в памяти. В этих случаях сам словарь занимал крошечную часть памяти.

В случае больших словарей нужно учитывать одну вещь - вручную настраивать и управлять емкостью словаря. При нормальных обстоятельствах .Net управляет этим штрафом (в текущей реализации, если ему не хватает места, он изменяет размер до простого числа, которое по крайней мере вдвое больше текущего размера словаря). Однако, если вы знаете, что собираетесь создать большой словарь или собираетесь расширять словарь вместо .Net, угадывая и изменяя размер словаря для вас (что является относительно дорогостоящим), то, вероятно, лучше сделать это самостоятельно (конечно, с начальным размер и, вероятно, управление более поздними размерами). Это можно сделать, управляя емкостью словаря, если у вас есть разумное эвристическое представление о том, какой должна быть емкость словаря. Microsoft рекомендует это наMSDN в своих комментариях к объекту Dictionary . Однако, похоже, что существуют некоторые споры относительно реальной ценности этого подхода, хотя я не уверен, насколько строгим является этот тест, и есть ли другие оптимизации, которые платформа .Net внедряет, когда словарь изменяется очень быстро.

Это полезный вопрос переполнения стека об объекте и размере памяти.

Практические ограничения могут быть связаны с машиной, на которой работает ваше программное обеспечение, а также с тем, сколько объектов вы фактически планируете содержать в этих структурах данных. Как упомянул Одед, int.MaxValue - это большое число, но соответствует ли 2 миллиарда пунктов практическому пределу? Хранение такого количества предметов в памяти, вероятно, не очень практично.

Поскольку в документации не указано, где физически хранятся данные и не указывается ограничение, я предлагаю вам провести эксперимент с максимальным ожидаемым размером, который у вас, вероятно, будет, и отметить системную память до и после выделения памяти.

Недавно я обновил перестрелку хэш-таблицы проекта github (здесь: https://github.com/jimbelton/hash-table-shootout ). Стандартная неупорядоченная карта gcc содержит около 1,8 ГБ служебных данных для хранения 40M объектов. Это кажется мне довольно отвратительным, но даже самый эффективный инструмент памяти, sparse_hash_map Google, занимает 600 Мбайт, и вы платите штраф за его использование. Если вам нужна скорость, из включенных алгоритмов, Glib GHashTable является самым быстрым и имеет хорошую производительность памяти (около 1,3 Гбайт). Результаты тестов размещены здесь: https://jimbelton.wordpress.com/2015/07/01/hash-table-shootout-on-github/