Практические ограничения размера Hashtable и Dictionary в c #

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

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

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

10 голосов | спросил JoeGeeky 7 WedEurope/Moscow2011-12-07T01:24:01+04:00Europe/Moscow12bEurope/MoscowWed, 07 Dec 2011 01:24:01 +0400 2011, 01:24:01

4 ответа


6

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

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

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

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

ответил AlexC 7 WedEurope/Moscow2011-12-07T02:46:57+04:00Europe/Moscow12bEurope/MoscowWed, 07 Dec 2011 02:46:57 +0400 2011, 02:46:57
2

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

ответил Bernard 7 WedEurope/Moscow2011-12-07T01:41:31+04:00Europe/Moscow12bEurope/MoscowWed, 07 Dec 2011 01:41:31 +0400 2011, 01:41:31
0

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

ответил NoChance 7 WedEurope/Moscow2011-12-07T02:47:12+04:00Europe/Moscow12bEurope/MoscowWed, 07 Dec 2011 02:47:12 +0400 2011, 02:47:12
0

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

ответил Jim Belton 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 04 Sep 2015 23:04:22 +0300 2015, 23:04:22

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132