Що .NET колекція забезпечує найшвидший пошук

У мене є предмети 60k, які потрібно перевірити у списку пошуку 20k. Чи існує об'єкт колекції (наприклад List, HashTable), який забезпечує виключно швидкий Contains()метод? Або мені доведеться писати своє? Іншими словами, це Contains()метод за замовчуванням просто сканування кожного елемента чи він використовує кращий алгоритм пошуку.

foreach (Record item in LargeCollection)
{
    if (LookupCollection.Contains(item.Key))
    {
       // Do something
    }
}

Примітка . Список пошуку вже відсортований.

У найзагальнішому випадку розгляньте System.Collections.Generic.HashSetструктуру даних "Містить" робочу конячку за замовчуванням, оскільки вона потребує постійного часу для оцінки Contains.

Фактична відповідь на тему "Що таке найшвидша колекція пошуку" залежить від конкретного розміру даних, упорядкованості, вартості хешування та частоти пошуку.

Якщо замовлення вам не потрібно, спробуйте HashSet<Record>(новий для .Net 3.5)

Якщо ви це зробите, скористайтесь List<Record>функцією " a" та дзвоніть BinarySearch.

Ви розглядали List.BinarySearch(item)?

Ви сказали, що ваша велика колекція вже сортована, тому це здається ідеальною можливістю? Хеш, безумовно, був би найшвидшим, але це спричиняє власні проблеми і вимагає набагато більше накладних витрат для зберігання.

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

Відповідно до результатів, BinarySearch on a List та SortedList були найкращими виконавцями, які постійно працювали на шиї, шукаючи щось як "значення".

Використовуючи колекцію, яка дозволяє "клавіші", Словник, ConcurrentDictionary, Hashset і HashTables виконали найкращі загальні результати.

Зберігайте обидва списки x і y у відсортованому порядку.

Якщо x = y, зробіть свою дію, якщо x <y, просуньте x, якщо y <x, просувайте y, поки жоден список не буде порожнім.

Час виконання цього перетину пропорційно min (розмір (x), розмір (y))

Не запускайте цикл .Contains (), це пропорційно x * y, що значно гірше.

Якщо можливо сортувати ваші предмети, то це набагато швидший спосіб зробити це, роблячи пошук ключів у хешбел чи b-дерево. Хоча, якщо ви предмети не сортуєте, то все одно їх не можна помістити в b-дерево.

У будь-якому випадку, якщо сортувати обидва списки, то це лише питання проходження списку пошуку по порядку.

Walk lookup list
   While items in check list <= lookup list item
     if check list item = lookup list item do something
   Move to next lookup list item

Якщо ви використовуєте .Net 3.5, ви можете зробити чистіший код, використовуючи:

foreach (Record item in LookupCollection.Intersect(LargeCollection))
{
  //dostuff
}

У мене немає. Net 3.5 тут, і це не перевірено. Він спирається на метод розширення. Чи не те, що LookupCollection.Intersect(LargeCollection), ймовірно , не те ж саме , як LargeCollection.Intersect(LookupCollection)... останній, ймовірно , набагато повільніше.

Це передбачає, що LookupCollection є a HashSet

Якщо ви не переживаєте про випинання кожного останнього біта виконання, пропозиція використовувати HashSet або бінарний пошук є надійною. Ваші набори даних просто недостатньо великі, щоб це було проблемою у 99% часу.

Але якщо це лише один раз у тисячі разів, коли ви збираєтеся це робити, а продуктивність є критичною (і це виявляється неприйнятним за допомогою HashSet / бінарного пошуку), ви, безумовно, можете написати свій власний алгоритм, який проходив би відсортовані списки, роблячи порівняння. До кожного списку можна було б пройти не більше одного разу, і в патологічних випадках не було б погано (коли ви проходили цей маршрут, ви, мабуть, побачите, що порівняння, припускаючи, що це рядок чи інше неінтегральне значення, було б справжнім витратом і що оптимізація буде наступним кроком).