Скорость поиска значения словаря .NET по ключу?

Question

У меня есть словарь из 10000 комбинаций «Продукт / Цвет / Размер», который я создал с чем-то вроде:

AllRecords = DB.ProductColourSizes _
             .ToDictionary(function(b) String.Format("{0}_{1}_{2}", _
             b.ProductCode, b.ColourCode, b.SizeCode))

Так что пример ключа похож на «13AI_GRS_M»

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

Я не знаю, как работает словарь внутри.Насколько быстро .NET находит правильное значение на основе такого ключа?Должен ли я сортировать запрос к базе данных, или у .NET есть какой-то другой способ определения ключа?

Или я должен преобразовать его в список и использовать словарь для определения правильного индекса?Или совсем другим способом?

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

Большое спасибо, Стив

Answer 1

Для того, что вы делаете, словарь идеален.

Время поиска по ключам для элементов в словаре составляет чертовски быстро , но в конечном итоге опирается на функцию хеш-кодаkey (в вашем случае string.GetHashCode()).

Вам повезло, потому что функция GetHashCode () строки .Net очень хороша.Если вы получите конфликт хеш-кода, .Net вызовет метод Equals для объекта, что гарантирует уникальность.

У нас есть словари с сотнями тысяч элементов, и время поиска незначительное.

Сортировка набора результатов из базы данных в этом случае не принесет пользы.

Надеюсь, это поможет.

Answer 2

Насколько быстро .NET находит правильное значение на основе такого ключа?

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

Также из MSDN:

Скорость поиска зависит от качества алгоритма хеширования типа, указанного дляTKey.

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

Answer 3

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

Answer 4

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

Вы можете написать свой собственный KeyClass с членами ProductCode, ColourCode и SizeCode, но тогда вам придется перегружать элементы GetHashCode и Equals (и связанные с ними).И это будет довольно сложно улучшить по сравнению с GethashCode System.String, и довольно легко будет делать ошибки.

Так что не беспокойтесь.Ваша строка ключей выглядит хорошо.

И если вы хотите оптимизировать, сначала профиль, чтобы увидеть, где ваши проблемы.

Answer 5

Я использую этот «шаблон» довольно часто, если вы не можете заставить запросы SQL (особенно в SQL CE) работать достаточно быстро.

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