Quale raccolta .NET offre la ricerca più veloce

Ho 60k articoli che devono essere verificati in un elenco di ricerca 20k. Esiste un oggetto di raccolta (come List, HashTable) che fornisce un Contains()metodo eccezionalmente veloce ? O dovrò scrivere il mio? In altre parole, il Contains()metodo predefinito è semplicemente scansionare ogni elemento o utilizza un algoritmo di ricerca migliore.

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

Nota . L'elenco di ricerca è già ordinato.

Nel caso più generale, considera System.Collections.Generic.HashSetla struttura dei dati predefinita del cavallo di lavoro "Contiene", poiché richiede tempo costante per la valutazione Contains.

La risposta effettiva a "Qual è la raccolta più rapida per la ricerca" dipende dalle dimensioni specifiche dei dati, dall'ordine, dal costo dell'hash e dalla frequenza di ricerca.

Se non hai bisogno di ordinare, prova HashSet<Record>(nuovo su .Net 3.5)

In tal caso, utilizzare a List<Record>e chiamare BinarySearch.

Hai preso in considerazione List.BinarySearch(item)?

Hai detto che la tua grande collezione è già ordinata, quindi questa sembra l'occasione perfetta? Un hash sarebbe sicuramente il più veloce, ma ciò comporta i propri problemi e richiede molto più overhead per l'archiviazione.

Dovresti leggere questo blog che ha testato rapidamente diversi tipi di raccolte e metodi per ognuno usando tecniche sia single che multi-thread.

Secondo i risultati, BinarySearch on a List e SortedList sono stati i migliori artisti che correvano costantemente testa a testa quando cercavano qualcosa come un "valore".

Quando si utilizza una raccolta che consente "chiavi", Dizionario, ConcurrentDictionary, Hashset e HashTables hanno ottenuto il miglior risultato complessivo.

Mantieni entrambi gli elenchi xey nell'ordine ordinato.

Se x = y, esegui la tua azione, se x <y, avanza di x, se y <x, avanza di y fino a quando uno dei due elenchi è vuoto.

Il tempo di esecuzione di questa intersezione è proporzionale a min (dimensione (x), dimensione (y))

Non eseguire un ciclo .Contains (), questo è proporzionale a x * y che è molto peggio.

Se è possibile ordinare i tuoi articoli, c'è un modo molto più veloce per farlo, quindi effettuare ricerche chiave in una tabella hash o b-tree. Tuttavia, se i tuoi oggetti non sono ordinabili, non puoi comunque metterli in un albero b.

Ad ogni modo, se ordinabile ordinare entrambi gli elenchi, allora è solo una questione di camminare nell'elenco di ricerca in ordine.

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

Se stai usando .Net 3.5, puoi creare un codice più pulito usando:

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

Non ho .Net 3.5 qui e quindi questo non è testato. Si basa su un metodo di estensione. Non che LookupCollection.Intersect(LargeCollection)probabilmente non è lo stesso di LargeCollection.Intersect(LookupCollection)... quest'ultimo è probabilmente molto più lento.

Ciò presuppone che LookupCollection sia a HashSet

Se non sei preoccupato di scricchiolare fino all'ultimo bit di performance, il suggerimento di utilizzare un HashSet o una ricerca binaria è solido. I tuoi set di dati non sono abbastanza grandi da essere un problema il 99% delle volte.

Ma se questa è solo una delle migliaia di volte che lo farai e le prestazioni sono fondamentali (e si dimostrano inaccettabili usando HashSet / ricerca binaria), potresti certamente scrivere il tuo algoritmo che camminava sugli elenchi ordinati facendo confronti mentre procedevi. Ogni elenco verrebbe camminato al massimo una volta e nei casi patologici non sarebbe male (una volta intrapreso questa strada probabilmente scopriresti che il confronto, supponendo che sia una stringa o un altro valore non integrale, sarebbe la vera spesa e che l'ottimizzazione sarebbe il prossimo passo).