.net - sacar - ¿Cómo mejorar el rendimiento de la recolección de basura?
servicio de recoleccion de basura pasa (6)
El aspecto más importante es minimizar la tasa de asignación. Cada vez que se asigna un objeto, necesita GC más tarde. Ahora, por supuesto, si el objeto es pequeño o de vida corta , se clavará en la generación joven (siempre que el GC sea generacional). Los objetos grandes tienden a ir directamente a la arena de tenencia. Pero evitar tener que recolectar es aún mejor.
Además, si puede lanzar cosas en la pila, disfrutará de mucha menos presión en el GC. Podría intentar jugar con las opciones de GC, pero creo que sería mucho mejor que lo ayudara con un generador de perfiles de asignación, para que pueda encontrar los puntos que generan los problemas.
Lo que debe tenerse en cuenta es el peso de las bibliotecas y marcos estándar. Envuelve un par de objetos y se llenará bastante rápido. Recuerde, cada vez que algo sucede en el GC-Heap, usualmente usa un poco más de espacio para la contabilidad del GC. Por lo tanto, sus 1000 punteros asignados individualmente son mucho más grandes que una matriz / vector de los mismos punteros ya que estos últimos pueden compartir la contabilidad del GC. Por otro lado, este último probablemente permanecerá vivo por mucho más tiempo.
¿Qué tipo de patrones de optimización se pueden usar para mejorar el rendimiento del recolector de basura?
Mi razón para preguntar es que hago un montón de software integrado usando Compact Framework. En dispositivos lentos, la recolección de basura puede convertirse en un problema, y me gustaría reducir las veces que el recolector de basura entra en funcionamiento, y cuando lo haga, quiero que termine más rápido. También puedo ver que trabajar con el recolector de basura en lugar de en contra de él podría ayudar a mejorar cualquier aplicación .NET o Java, especialmente las aplicaciones web de servicio pesado.
Aquí están algunos de mis pensamientos, pero no he hecho ningún punto de referencia.
- reutilización de clases / matrices temporales (mantener el recuento de asignaciones)
- manteniendo la cantidad de objetos en vivo al mínimo (colecciones más rápidas)
- intenta usar estructuras en lugar de clases
Escuché un show .NET Rocks en Rotor 2.0 . Si eres realmente hardcore, puedes descargar Rotor, modificar la fuente y usar tu propio recolector de basura modificado.
En cualquier caso, ese podcast tiene buena información sobre el GC. Recomiendo escucharlo.
La cuestión de la estructura frente a la clase es compleja ... por ejemplo, puede terminar fácilmente usando mucho más espacio en la pila. Y ciertamente no quieres estructuras mutables. Pero los otros puntos parecen razonables, siempre y cuando no estés doblando el diseño fuera de forma para acomodarlo.
[editar] Otro problema común es la concatenación de cadenas; si está haciendo concatenación en un bucle, use StringBuilder, que eliminará muchas cadenas intermedias. ¿Podría ser que GC está ocupado recogiendo todas las tensiones abandonadas de tus hilos?
Otra opción sería recolectar manualmente la basura durante horas no pico en su aplicación utilizando GC.Collect () (suponiendo que esté disponible en CF). Esto podría reducir los objetos necesarios para la limpieza más adelante en su aplicación.
La clave es entender cómo funciona el CF GC para las asignaciones. Se trata de un GC no generacional de marcado y barrido simple con algoritmos específicos para lo que activará un GC, y lo que causará la compactación y / o cabeceo después de la recolección. No hay casi nada que pueda hacer a nivel de aplicación para controlar el GC (el único método disponible es Recolectar, y su uso es bastante limitado, ya que no puede forzar la compactación de todos modos).
La reutilización de objetos es un buen comienzo, pero simplemente mantener baja la cantidad de objetos es probablemente una de las mejores herramientas, ya que todas las raíces se deben recorrer para cualquier operación de recolección. Mantener esa caminata corta es una buena idea. Si la compactación te está matando, entonces prevenir la fragmentación del segmento te ayudará. Los objetos> 64k pueden ser útiles en ese sentido, ya que obtienen su propio segmento y se tratan de manera diferente que los objetos más pequeños.
Para comprender realmente cómo funciona el CF GC, recomendaría ver el webcast de MSDN en la administración de la memoria CF.
Un hecho importante es mantener la vida de sus objetos lo más corta posible.