Что быстрее найти элемент в хэш-таблице или в отсортированном списке?

Что быстрее найти элемент в хэш-таблице или в отсортированном списке?

23
hashtable lookup performance sortedlist

7 ответов

сложность алгоритма-хорошая вещь, чтобы знать, и хэш-таблицы, как известно,O (1) в то время как отсортированный вектор (в вашем случае, я думаю, лучше использовать отсортированный массив, чем список) предоставит O (log n) время доступа.

но вы должны знать, что нотация сложности дает вам время доступа для n, идущего в бесконечность. Это означает, что если вы знаете, что ваши данные будет расти, нотация сложности дает вам некоторый намек на алгоритм для выбора.

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

например, в другой проблеме: сортировка массива. Для несколько записей сортировка пузырьком в то время как O (N^2) может быть быстрее, чем .. быстрый вид, пока это O (N log n).

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

Edit: посмотрите на эту статью, чтобы понять значение обозначения Big O .

26

предполагая, что под "отсортированным списком" вы подразумеваете "случайную доступную, отсортированную коллекцию". Список имеет свойство, что вы можете пересекать его только элемент за элементом, что приведет к сложности O(N).

самый быстрый способ найти элемент в отсортированной индексируемой коллекции-это N-ary search, O(logN), в то время как хэш-таблица без коллизий имеет сложность поиска O (1).

13

Если алгоритм хэширования очень медленный (и / или плохой), хэш-таблица будет быстрее.

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

7

на get работы в SortedList is O(log n) в то время как та же операция e HashTable является O(1). Итак,обычно на HashTable было бы намного быстрее. Но это зависит от ряда факторов:

  • размер
  • производительность алгоритма хэширования
  • число столкновений / качество алгоритма хэширования
5

это полностью зависит от объема данных, которые вы сохранили.

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

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

таким образом, в целом, отсортированный список, как правило, будет быстрее для небольших наборов данных. (Для чрезвычайно малых наборов данных, которые часто изменяются и/или редко ищутся,unсортированный список может быть еще быстрее, так как он позволяет избежать накладных расходов на сортировку.) Поскольку набор данных становится большим, рост времени поиска списка затмевает фиксированные накладные расходы хэширования, и хэш-таблица становится быстрее.

где эта точка останова будет меняться в зависимости от вашей конкретной хэш-таблицы и отсортированный список-поиск реализаций. Выполните тесты и тесты производительности на ряде наборов данных типичного размера, чтобы увидеть, что на самом деле будет работать лучше в вашем конкретном случае. (Или, если код уже работает "достаточно быстро", не делайте этого. Просто используйте то, что вам удобнее, и не беспокойтесь об оптимизации того, что не нужно оптимизировать.)

3

в некоторых случаях, это зависит от размера коллекции (и в меньшей степени, детали реализации). Если ваш список очень маленький, 5-10 пунктов, возможно, я бы предположил, что список будет быстрее. Иначе xtofl имеет право.

1

HashTable будет более эффективным для списка, содержащего более 10 элементов. Если список содержит менее 10 элементов, накладные расходы из-за хэширования algo будут больше.

в случае, если вам нужен быстрый словарь, но также необходимо сохранить элементы в порядке, используйте OrderedDictionary. (.Net 2.0 и далее)

0