Utilizzerò un dizionario in un progetto .NET per archiviare un numero elevato di oggetti. Pertanto ho deciso di utilizzare una stringa GUID come chiave, per garantire chiavi univoche per ogni oggetto.La lunghezza della chiave influisce sulle prestazioni del dizionario?
Una chiave grande come un GUID (o anche più grandi) diminuisce le prestazioni di un dizionario, ad es. per recuperare un oggetto tramite la sua chiave?
Grazie, Andrej
Si consiglia di utilizzare uno effettivo anziché la rappresentazione di stringa dello Guid. Sì, quando si confrontano le stringhe la lunghezza influisce sul numero di operazioni richieste, poiché deve confrontare le stringhe carattere per carattere (al minimo, questo esclude qualsiasi opzione speciale come IgnoreCase). L'attuale Guid fornisce solo 16 byte per il confronto anziché il minimo di 32 nello string.
Detto questo, molto probabilmente non noterete alcuna differenza ... l'ottimizzazione prematura e tutto il resto. Vorrei semplicemente andare per la chiave Guid poiché questo è ciò che i dati è.
Sì e no. Le stringhe più grandi aumentano le dimensioni della memoria di un dizionario. E le taglie più grandi significano tempi leggermente più lunghi per calcolare le dimensioni dell'hash.
Ma preoccuparsi di queste cose è probabilmente l'ottimizzazione prematura. Anche se sarà più lento, non è qualcosa che probabilmente noterai.
A quanto pare. Ecco un buon test: Dictionary String Key Test
Non è un test davvero valido in quanto mostra un aumento delle prestazioni di soli 3 secondi per 100 milioni di ricerche nel dizionario quando si confrontano i tasti di 2 e 20 caratteri. Questo non è un guadagno significativo nella maggior parte degli usi di un dizionario. –
2 caratteri: 1,5 secondi. 20 caratteri: 4,5 secondi. Poiché questi 3 secondi equivalgono a un fattore 3 di miglioramento, penso che sia significativo. A lungo, ovviamente, dato che la ricerca del dizionario è il passo più lento nell'elaborazione. –
La dimensione effettiva di un oggetto rispetto al recupero dei valori è irrilevante. La velocità di ricerca dei valori è molto più dipendente dalla velocità dei due metodi sul passata IEqualityComparer<T> esempio
EDIT
Molte persone utilizzano String come giustificazione per affermare che la dimensione di un oggetto più grande riduce le prestazioni di ricerca. Questo deve essere preso con un granello di sale per diverse ragioni.
IEqualityComparer<String> in modo tale che la lunghezza della stringa era irrilevante.Devi ancora ricorrere alla stringa per confrontarla, in primo luogo, quindi le dimensioni ostacoleranno le prestazioni indipendentemente dal tuo algoritmo. – Blindy
@Blindy no non lo fai. Dipende tutto da quello che penso siano stringhe uguali nel mio confronto. Forse mi interessa solo il primo prefisso di 3 lettere? Forse solo la prima lettera. Oppure dico solo che le stringhe non nulle sono uguali. Nessuno di questi varierà di dimensioni man mano che la stringa diventa più grande – JaredPar
Questo non sembra applicarsi all'OP, quindi ha bisogno di confronti completi su chiavi guid-like. – Blindy
Ho fatto una rapida ricerca su Google e ho trovato questo articolo.
http://dotnetperls.com/dictionary-string-key
Si conferma che le chiavi generalmente più brevi un rendimento migliore rispetto a quelli più lunghi.
Questo non è un buon test in quanto mostra un guadagno di prestazioni di soli 3 secondi per 100 milioni di ricerche nel dizionario quando si confrontano i tasti di 2 e 20 caratteri. la maggior parte degli usi di un dizionario: in ogni utilizzo del mondo reale dei dizionari che riesco a trovare, i guadagni delle prestazioni saranno in nano secondi, quindi la tua affermazione "che le chiavi generalmente più brevi hanno prestazioni migliori di quelle più lunghe" è fuorviante. insignificante. –
vedere Performance - using Guid object or Guid string as Key per una domanda simile. Puoi testarlo con una chiave alternativa.
Infatti, l'hashing di un Guid sarà considerevolmente più veloce dell'hashing di una stringa di 32 caratteri +1 – spender
Grazie, sembra ragionevole – Andrej
CLR? (Hashtable creato internamente per tenere traccia delle stringhe) – boli