Cuando a la dirección administrada fragmentación del montón

Question

Yo estaba leyendo un href="http://joshsmithonwpf.wordpress.com/2007/08/29/a-base-class-which-implements-inotifypropertychanged/" rel="nofollow noreferrer"> entrada de blog por Josh Smith donde se utiliza un mecanismo de caché con el fin de "reducir la fragmentación del montón administrado". Su almacenamiento en caché reduce el número de objetos de corta duración que se creó a costa de un poco más lenta la velocidad de ejecución.

¿Cuánto de un problema se gestiona la fragmentación del montón en un lenguaje administrado como C #? ¿Cómo se puede diagnosticar si se trata de un problema? ¿En qué situaciones sería normalmente necesidad de abordarlo?

Answer 1

  

Cuando

No es demasiado rápido. En general, es muy barato para tener objetos de corta vida. Para una caché sea rentable tendría que ser (muy) muchos candiadates y que debe vivir el tiempo suficiente para llegar a la siguiente generación.

  

¿Cómo se puede diagnosticar si se trata de un problema?

Con un generador de perfiles. No estoy tan seguro de que el autor del artículo que hice.

  

¿Cuánto de un problema se gestiona la fragmentación del montón en un lenguaje administrado como C #?

Por lo que yo sé, es raro. NET tiene un recolector de basura de compactación, que impide que la mayoría de las formas de fragmentación. Hay problemas con el objeto grande Montón veces.

---

Editar:

Cuando usted va a través de los comentarios a continuación el artículo encontrará que alguien lo midió y encontró el caché a ser mucho más lento que la creación de nuevos EventArgs cada vez.

Conclusión: Medida antes de empezar a optimizar. Esto no era una buena idea / ejemplo.

Answer 2

A no ser que se trata de 10K + pequeños objetos de corta vida por segundo, no debería ser un problema en absoluto en un ordenador moderno con cantidad razonable de memoria RAM.

Así que primero debe ejecutar el código en todos los escenarios razonables y si es lo suficientemente rápido -. No se preocupe por ella

Si no está satisfecho con la velocidad, se ve que el código en algún momento '' estrangulaciones o una curiosidad, puede supervisar varias estadísticas de memoria .NET ( http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx ) en el monitor de rendimiento de aplicaciones (viene como parte de Windows ). Específicamente usted está interesado en% Tiempo en GC.

Redgate HORMIGAS perfilador también el seguimiento de estas estadísticas.

Answer 3

Gestionado fragmentación del montón es generalmente debido a la fijación de objetos. Los objetos se ven puestas en código administrado pasa el puntero del objeto al código nativo y el objeto no se pueden mover porque la referencia se pasa al código nativo. Esto es muy común cuando hay una gran cantidad de actividades de E / S. Como se mencionó anteriormente, por lo general ocurre sólo en LOH.

Aquí está un ejemplo de La fragmentación en Gen0 Montón

Answer 4

A diferencia de otras respuestas que se dan aquí Estado I: sí, uno debe tener cuidado de fragmentación! No sólo se aplica a montones administrados sino a todas las aplicaciones de manipulación (por lo menos)

• muchos "grandes" en Recursos
• un patrón de asignación pesada.

Desde el LOB no quede compactado, que - con el tiempo - lo más probable que se fragmentan en cuanto el tamaño y número de los objetos superar un valor determinado (que se refiere a la HEAPSIZE máximo total disponible). Si lo hace, la única manera segura es limitar el número de referencias al instante holded a esos objetos. Una memoria caché (piscina) sólo ayudaría, si los objetos agrupados pueden ser reutilizados. A veces, si estos están hechos de Recursos matrices de longitud variable F. E., que podría no ser reutilizable fácilmente. Así que la agrupación no puede ayudar mucho aquí.

¿Cómo detectarlo? Siempre que hay una gran presión sobre el montón de LOB. ¿Cómo saber que es? Utilice el contador de rendimiento .NET "Colección Conde Gen 0 ... 2" al mismo tiempo. Si hay demasiados objetos grandes se asignan desde el LOB, todos los contadores evolucionarán de forma idéntica. Es decir, básicamente, todas las colecciones son caros generación 2 colecciones. En ese caso, no se debe hacer algo.

En cuanto a los objetos más pequeños, que permitiría que el GC haga todo el trabajo en Gen 0 colecciones y preocupación Dont.