Более быстрая замена к Словарю <TKey, TValue>

Я согласен с предположением Джона Скита , что это, скорее всего, JIT-компиляция.

При этом я хотел добавить сюда некоторую другую информацию:

] Большинство проблем со скоростью, связанных с использованием Dictionary , не связаны с реализацией Dictionary. Dictionary ОЧЕНЬ быстро работает прямо из коробки. Было бы трудно превзойти его.

Проблемы со скоростью, связанные с экземплярами Dictionary, почти всегда на самом деле являются проблемами реализации хэш-кода. Если у вас возникают проблемы со скоростью при использовании Dictionary , вернитесь к реализации GetHashCode () , которую вы определили в MyCustomClass. Это еще более важно, если вы используете настраиваемую структуру в качестве ключа.

Чтобы получить хорошую производительность от Dictionary, GetHashCode () должен быть:

1. Fast
2. Способен предоставлять хэш-коды, которые вызывают небольшое количество конфликтов. По возможности уникальные экземпляры должны генерировать уникальные хеш-значения.

Если вы все правильно поняли, я думаю, вы будете очень довольны реализацией словаря по умолчанию.

Не забывайте, что вы также синхронизируете конструктор словаря в этом коде. Я провел тест, переместив вызов конструктора из измерения, и зациклился 10 раз. Вот мой тестовый код:

for (int i = 0; i < 10; i++)
{
    Dictionary<string, string> test = new Dictionary<string, string>();

    System.Diagnostics.Stopwatch watch = System.Diagnostics.Stopwatch.StartNew();

    test.Add("fieldName", "fieldValue");
    test.Add("Title", "fieldavlkajlkdjflkjalkjslkdjfiajwelkrjelrkjavoijl");

    Console.WriteLine(watch.Elapsed);
}

Console.ReadKey();

Ниже приведены результаты:

00:00:00.0000607
00:00:00.0000025
00:00:00.0000015
00:00:00.0000015
00:00:00.0000016
00:00:00.0000017
00:00:00.0000016
00:00:00.0000016
00:00:00.0000016
00:00:00.0000015

Я не уверен, насколько быстрее вы можете это сделать ...

Обновление

Похоже, это также отражает результаты Джона Скитса ... JIT.

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

Я бы хотел избегайте использования Contains, если это возможно, и посмотрите TryGetValue и т. д.

Скорее всего, вы не найдете ничего быстрее, чем Словарь. Я бы просто использовал словарь. Затем, когда вы видите, что не достигли своих целей по производительности, а профилировщик указывает, что добавление / удаление из словаря является узким местом, которое вы можете заменить на более целевой класс.

Обратите внимание, что такие функции, как LINQ, не влияют на производительность убыток, если вы ими не воспользуетесь.

Не могли бы вы использовать список и определить перечисление, например, fieldName = 0, Title = 1 и использовать уникальный индекс каждого свойства в качестве индекса поиска в списке? Это будет самое быстрое решение, хотя и наименее гибкое, поскольку вы будете привязаны к перечислению.

Сколько элементов вы планируете добавить в словарь? Хотя Dictionary / Hashtable обычно самый быстрый, в зависимости от того, что вы делаете, может быть что-то более быстрое (также более подходящее), чем Hashtable (основная структура в Dictionary). В зависимости от использования, возможно, что SortedList может быть быстрее, если объединить его с каким-то списком пропуска или даже самобалансирующимся деревом или попытками. Особенно, если вы хотите вернуть диапазон значений, а не одно значение.

Хеш-таблица хорошо подходит, когда:

1. Вы знаете, сколько элементов вы собираетесь сохранить до начала заполнения таблицы. Динамическое изменение размера будет очень болезненным!
2. У вас есть хороший алгоритм хеширования с равномерным распределением, что и делает .NET
3. Существует хороший механизм разрешения конфликтов, который. NET делает
4. Вы ищете одно значение
5. Вы можете гарантировать, что все значения будут уникальными

Если вы выполняете некоторое сжатие, например, RB-Tree лучше, чем Hashtable.

] Источник: http://en.wikipedia.org/wiki/Hashtable#Dynamic_resizing