Практичні обмеження розміру хешбела та словника в c #

Які практичні обмеження для кількості елементів, які може містити Словник C # 4 або Hashtable, і загальна кількість байтів, які ці структури можуть містити. Я буду працювати з великою кількістю об'єктів і хочу знати, коли у цих структур починають виникати проблеми.

Для контексту я буду використовувати 64-бітну систему з тоннами пам'яті. Крім того, мені потрібно буде знайти об’єкти за допомогою якоїсь форми або "ключа". Враховуючи вимоги до продуктивності, цим об’єктам потрібно буде залишатися в пам'яті, і багато хто буде довгоживучим.

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

Одне, що слід зазначити, - це те, що словник не може містити сам об’єкт (який може мати великий слід пам'яті), а лише посилання на об'єкт, тому якщо об'єкти складні, це не впливає на розмір словника.

Я зібрав кілька тисяч предметів разом зі Словника в пам’яті, і питання полягає не в розмірі Словника, а в розмірі самих об’єктів в пам'яті. У цих випадках сам словник був крихітною частиною пам'яті.

Одне, про що слід думати у випадках великих словників, - це налаштування та керування ємністю словника вручну. За звичайних обставин. Net штрафує цей штраф (у поточній реалізації, якщо у нього не вистачає місця, він змінює розмір до простого числа, що становить щонайменше вдвічі більше поточного розміру словника). Однак якщо ви знаєте, що ви збираєтеся створити великий словник або збираєтесь розширити словник замість .Net здогадуватися та змінювати розмір словника для вас (що є відносно дорогим), напевно, краще робити це самостійно (звичайно з початковим розмір і, можливо, керування пізнішими розмірами). Це можна зробити, керуючи ємністю словника, якщо ви маєте розумне евристичне уявлення про те, якою має бути спроможність словника. Microsoft рекомендує це робити даліMSDN у своїх зауваженнях щодо об’єкта Словник . Однак, мабуть, виникають дебати щодо реальної цінності цього підходу, хоча я не впевнений, наскільки жорсткий цей тест і чи є інші оптимізації, які платформа .Net застосовує, коли словник надзвичайно швидко змінює розмір.

Це корисне запитання про переповнення стека щодо розміру об'єкта та пам'яті.

Практичні обмеження можуть залежати від машини, на якій працює ваше програмне забезпечення, а також кількості об'єктів, які ви дійсно плануєте містити в цих структурах даних. Як згадував Одід, int.MaxValue - це велика кількість, але 2 мільярди предметів прирівнюються до практичної межі? Збереження того, що багато предметів у пам'яті, ймовірно, не дуже практично.

Оскільки в документації не вказано, де фізично зберігаються дані, і не визначено межу, я пропоную вам здійснити експеримент із максимальним очікуваним розміром, який ви, можливо, матимете, та відзначте системну пам'ять до та після розподілу пам’яті.

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