2010-09-01 20 views
5

¿Qué significa dotTrace Performance Profiler en [Recolección de basura]?

¿Qué significa [Recolección de basura] en esta foto? ¿Y las "20 llamadas"?

Quiero decir, ¿cómo puedo averiguar por qué GC tomó tanto tiempo? ¿Estaba recolectando muchos objetos pequeños? ¿Uno solo grande? ¿Alguna pista sobre cómo optimizar esto en absoluto?

El código en cuestión es:

private void DeserializeFrom(SerializationInfo info) 
{ 
    Width = info.GetInt32("width"); 
    Height = info.GetInt32("height"); 
    var data = (List<byte>)info.GetValue("cells", typeof(List<byte>)); 
    cells = new Cell[physicalSize.Width, physicalSize.Height]; 
    int pos = 0; 
    for (int x = 0; x < physicalSize.Width; x++) 
    { 
     for (int y = 0; y < physicalSize.Height; y++) 
     { 
      cells[x, y] = new Cell(); 
      if (x < Width && y < Height) 
      { 
       cells[x, y].HasCar = data[pos]; 
       pos++; 
      } 
     } 
    } 
} 

pero nada de lujos. Sospecho que el culpable es el gran objeto List<byte>, pero pensé que la recopilación de un único, gran objeto se supone que es instantáneo (en lugar de recoger un grupo de objetos pequeños).

Respuesta

1

Un poco tarde para la fiesta, pero si está utilizando .Net entonces está usando código administrado, lo que básicamente significa que el tiempo de ejecución .Net dispone sus objetos en consecuencia para que no tenga pérdidas de memoria en lugar de C o C++ .

La recolección de elementos no utilizados siempre que el tiempo de ejecución demore un tiempo en administrar la asignación y el lanzamiento de la memoria para la aplicación. En este caso, eso es lo que está sucediendo.

Por favor, eche un vistazo a este filtro que se puede usar con doTrace (tengo la versión 6) para que pueda analizar la recolección de basura y determinar cuándo podría estar bloqueando su ejecución. https://www.jetbrains.com/profiler/help/CLR_Activity.html

+0

Me doy cuenta de que esto tiene algunos meses, pero creo que vale la pena mencionar que definitivamente puede haber pérdidas de memoria en el código .net. Los eventos estáticos son una causa muy común de esto. Si se suscribe a un evento estático con un transitorio y no cancela la suscripción del evento antes de liberar todas las referencias conocidas al transitorio, el transitorio se mantendrá con vida por la referencia del evento estático; el recolector de basura nunca lo recogerá. – Kelsie

+0

@kelsie tienes razón y no me expresé correctamente. No tiene pérdidas de memoria con respecto a cómo solía programar con código no administrado donde era fácil simplemente no desasignar un objeto correctamente y tener una pérdida de memoria. Además, como bien indica, los eventos son una forma en que puede mantener una referencia a un objeto para que no se elimine. – xmorera

+0

Otra posibilidad estaba en pre 4.5 con el gran montón de objetos cuando tu aplicación era muy intensiva en el uso de matrices que estaban asignadas en el LOH y dado que antes no podías compactar el LOH, podías salirte de las excepciones de memoria. – xmorera

Cuestiones relacionadas