Limiti delle dimensioni pratiche di un hashtable e dizionario in c #

Una cosa da sottolineare è che il dizionario non terrà l'oggetto stesso (che potrebbe avere un ingombro di memoria di grandi dimensioni) ma solo un riferimento all'oggetto, quindi se gli oggetti sono complessi questo non ha alcun impatto sulle dimensioni del dizionario .

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

Una cosa su cui riflettere nei casi di dizionari di grandi dimensioni è la configurazione e la gestione manuale della capacità del dizionario. In circostanze normali .Net gestisce questa multa (nell'implementazione corrente se esaurisce lo spazio ridimensiona ad 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 che espanderai il dizionario al posto di .Net e inducendo a ridimensionare il dizionario per te (che è relativamente costoso) è probabilmente meglio farlo tu stesso (certamente con l'iniziale dimensione 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 consiglia questo su MSDN nelle loro osservazioni sull'oggetto Dizionario . Tuttavia, sembra esserci un dibattito su 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 sta ridimensionando estremamente rapidamente .

Questa è una utile domanda Overflow dello stack sull'oggetto e dimensioni della memoria.

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 ha affermato Oded, int.MaxValue è un numero elevato, ma 2 miliardi di articoli equivalgono a un limite pratico? Memorizzare molti elementi in memoria probabilmente non è molto pratico.

Poiché la documentazione non indica dove sono archiviati fisicamente i dati e non specifica il limite, ti suggerisco di eseguire un esperimento con le dimensioni massime previste che probabilmente avrai e di notare la memoria di sistema prima e dopo la memorizzazione allocazione.

Recentemente ho aggiornato il progetto github hash-table-shootout (qui: link ). La mappa standard senza gcc ha circa 1,8 GB di overhead per memorizzare oggetti da 40M. Questo mi sembra abbastanza atroce, ma anche la memoria più performante, la sparse_hash_map di Google, impiega 600 Mbyte e tu paghi una penalità sulle prestazioni per utilizzarla. Se si desidera la velocità, degli algoritmi inclusi, la GHashTable di Glib è la più veloce e ha buone prestazioni di memoria (circa 1.3 Gbyte di sovraccarico). I risultati del benchmark sono pubblicati qui: link