Limiti pratici di dimensione di un hashtable e di un dizionario in c #


12

Quali sono i limiti pratici per il numero di elementi che può contenere un dizionario C # 4 o Hashtable e il numero totale di byte che queste strutture possono ragionevolmente contenere. Lavorerò con un gran numero di oggetti e voglio sapere quando queste strutture iniziano a riscontrare problemi.

Per il contesto, userò un sistema a 64 bit con tonnellate di memoria. Inoltre, dovrò trovare oggetti usando una forma o 'chiave'. Date le esigenze prestazionali, questi oggetti dovranno risiedere nella memoria e molti dureranno a lungo.

Sentiti libero di suggerire altri approcci / modelli, anche se devo evitare di utilizzare librerie di terze parti o open-source. Per motivi di specifica, devo essere in grado di crearlo usando C # ( o C ++ \ CLI ) nativo .


1
Dovrebbero essere necessarie solo un'ora o due per deridere quella roba e misurare le prestazioni di aggiunta / rimozione / ricerca in base a diversi utilizzi / carichi. Credo che VS2010 fornisca anche uno scheletro di test delle prestazioni per te. Indipendentemente da ciò che qualcuno dice qui, il codice che scriverai avrà il tuo nome su di esso, direttamente o nei metadati.
Giobbe

Risposte:


8

Una cosa da sottolineare è che il Dizionario non trattiene l'oggetto stesso (che può avere un ingombro di memoria elevato) ma solo un riferimento all'oggetto, quindi se gli oggetti sono complessi questo non ha alcun impatto sulla dimensione del Dizionario.

Ho raccolto diverse migliaia di oggetti insieme in un dizionario in memoria e il problema non è la dimensione del dizionario ma la dimensione degli oggetti stessi nella memoria. In questi casi il Dizionario stesso era una piccola porzione della memoria coinvolta.

Una cosa a cui pensare nei casi di grandi dizionari è la configurazione e la gestione manuale della capacità del dizionario. In circostanze normali .Net gestisce questa multa (nell'attuale implementazione se esaurisce lo spazio si ridimensiona a un numero primo che è almeno il doppio della dimensione corrente del Dizionario). Tuttavia, se sai che stai per creare un dizionario di grandi dimensioni o stai per espandere il dizionario anziché .Net indovinando e ridimensionando il dizionario per te (che è relativamente costoso) è probabilmente meglio che tu lo faccia da solo (sicuramente con l'iniziale dimensioni e probabilmente gestendo ridimensionamenti successivi). Questo può essere fatto gestendo la capacità del Dizionario se si ha una ragionevole idea euristica di quale dovrebbe essere la capacità del Dizionario. Microsoft lo consiglia suMSDN nelle loro osservazioni sull'oggetto Dizionario . Tuttavia, sembra esserci un dibattito sul valore reale di questo approccio, anche se non sono sicuro di quanto sia rigoroso quel test e se ci sono altre ottimizzazioni che la piattaforma .Net mette in atto quando un dizionario viene ridimensionato in modo estremamente rapido.

Questa è un'utile domanda di Stack Overflow sull'oggetto e sulla dimensione della memoria.


2

I limiti pratici possono essere relativi alla macchina su cui è in esecuzione il software e al numero di oggetti che si prevede di contenere all'interno di queste strutture di dati. Come menzionato Oded, int.MaxValue è un numero elevato, ma 2 miliardi di articoli equivalgono a un limite pratico? La memorizzazione di molti elementi in memoria probabilmente non è molto pratica.


0

Poiché la documentazione non indica dove sono archiviati fisicamente i dati e non specifica il limite, ti suggerisco di eseguire un esperimento con la dimensione massima prevista che potresti avere e annotare la memoria di sistema prima e dopo l'allocazione della memoria.


-1

Di recente ho aggiornato il progetto github hash-table-shootout (qui: https://github.com/jimbelton/hash-table-shootout ). La mappa non ordinata gcc standard ha circa 1,8 GByte di overhead per memorizzare oggetti 40M. Questo mi sembra abbastanza atroce, ma anche la memoria con le migliori prestazioni, la sparse_hash_map di Google, richiede 600 Mbyte e paghi una penalità prestazionale per usarla. Se si desidera la velocità, degli algoritmi inclusi, la Glib GHashTable è la più veloce e ha buone prestazioni di memoria (circa 1,3 Gbyte in testa). I risultati del benchmark sono pubblicati qui: https://jimbelton.wordpress.com/2015/07/01/hash-table-shootout-on-github/

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.