Quando l'indirizzo gestito frammentazione heap

Question

Stavo leggendo un blog da Josh Smith dove ha usato un meccanismo di cache al fine di "ridurre la frammentazione degli heap gestito". La sua cache riduce il numero di oggetti di breve durata viene creato a costo di leggermente più lenta velocità di esecuzione.

Quanto di un problema è gestito frammentazione heap in un linguaggio gestito come C #? Come è possibile diagnosticare se si tratta di un problema? In quali situazioni sarebbe in genere bisogno di indirizzo esso?

Answer 1

  

Quando

Non troppo in fretta. In genere è molto a buon mercato di avere oggetti di breve durata. Per una cache per essere redditizia ci sarebbe dovuto essere (molto) molti candiadates e dovrebbero vivere abbastanza a lungo per rendere alla generazione successiva.

  

Come si può diagnosticare se si tratta di un problema?

Con un Profiler. Io non sono così sicuro l'autore dell'articolo fatto.

  

Quanto di un problema è gestito frammentazione heap in un linguaggio gestito come C #?

Per quanto ne so è raro. NET ha un collettore immondizia compattazione, che impedisce molte forme di frammentazione. Ci sono problemi con il Large Object Heap volte.

---

Modifica:

Quando si passa attraverso i commenti sotto l'articolo troverete che qualcuno misurato e trovato la cache di essere molto più lento rispetto alla creazione di nuovi EventArgs ogni volta.

Conclusione: Misura prima di iniziare l'ottimizzazione. Questa non era una buona idea / esempio.

Answer 2

A meno che non avete a che fare con 10K + piccoli oggetti di breve durata al secondo, non dovrebbe essere un problema a tutti su un computer moderno con ragionevole quantità di RAM.

Quindi, prima si dovrebbe eseguire il codice in tutti gli scenari ragionevoli e se è abbastanza veloce -. Non ti preoccupare

Se non siete soddisfatti con la velocità, si vede che il codice Sometime 'strozzatori' o un solo curiosi, è possibile monitorare varie statistiche di memoria NET ( http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx ) in Monitor di app (si presenta come parte di Windows ). In particolare ti interessa% tempo in GC.

Redgate ANTS Profiler controlla anche queste statistiche.

Answer 3

frammentazione heap gestito è di solito a causa di pinning di oggetti. Gli oggetti vengono riposte quando il codice gestito passa il puntatore oggetto al codice nativo e l'oggetto non possono essere spostati perché è passato il riferimento al codice nativo. Questo è molto comune quando c'è un sacco di attività di I / O. Come accennato in precedenza di solito succede solo in LOH.

Ecco un esempio di La frammentazione in Gen0 Heap

Answer 4

A differenza di altre risposte qui riportati stato io: sì, si dovrebbe prendere cura di frammentazione! Esso non si applica solo ai cumuli gestiti, ma per tutte le applicazioni di movimentazione (almeno)

• molti "grandi" le risorse in
• un modello di allocazione pesante.

Dato che il LOB non viene compattato, è - nel corso del tempo - molto probabilmente otterrà frammentato, non appena le dimensioni e il numero di oggetti superiore a un certo valore (che si riferisce alla heapsize massimo totale disponibile). Se lo fa, l'unico modo sicuro è quello di limitare il numero di riferimenti istantaneamente holded a tali oggetti. Una cache (piscina) sarebbe solo aiutare, se gli oggetti in pool possono essere riutilizzati. A volte, se questi le risorse sono fatte di array di lunghezza variabile f.e., essi potrebbero non essere riutilizzabili facilmente. Così il pool non può aiutare molto qui.

Come rilevarla? Quando mai c'è grande pressione sul mucchio LOB. Come per scoprire che è? Utilizzare il contatore delle prestazioni .NET "Count Collection Gen 0 ... 2" allo stesso tempo. Se troppi oggetti grandi vengono allocati dalla LPP, tutti i contatori evolveranno identicamente. Che significa, in pratica tutte le collezioni sono costosi di generazione di 2 collezioni. In tal caso, non ci dovrebbe essere fatto qualcosa.

Per quanto riguarda gli oggetti più piccoli, vorrei lasciare che il GC fare tutto il lavoro in Gen 0 collezioni e preoccupazione Dont.