Analizador de Visual Studio, cómo rastrear el uso de [clr.dll]

Question

Cuando uso el generador de perfiles en Visual Studio para buscar funciones costosas, he visto en ocasiones que la mayor parte del trabajo termina en [clr.dll] . Eso básicamente equivale a una caja negra, y me pregunto si hay alguna forma de rastrear por qué está pasando tanto tiempo allí.

Supongo que clr.dll maneja cosas como la compilación JIT, cargando ensambles y administrando aplicaciones, recolección de basura, reflexión, etc. Pero hace que sea realmente difícil saber qué código hace que pase tanto tiempo.

Obviamente, es otro código, además del tiempo de ejecución en sí, el que está haciendo que pase tanto tiempo en clr.dll, entonces, ¿cómo rastrear qué código tiene la culpa?

Answer 1

Necesita saber qué parte de su código - el código que puede editar y compilar, que es el único código que puede corregir - qué parte de ese código es responsable de un porcentaje sustancial de tiempo que se utiliza.

No es bueno saber que clr.dll está utilizando mucho tiempo a menos que pueda saber qué parte de su código es responsable de ello.

Esa información está en la pila de llamadas.

Si tiene un método, o incluso una sola línea de código, que está en la pila durante un cierto porcentaje de tiempo, como el 20%, entonces es responsable de aproximadamente ese porcentaje de tiempo. Si pudiera eliminar de alguna manera esa línea de código (o hacer que tome mucho menos tiempo) que el 20% del tiempo total se convertiría en cero, o casi tan, lo que le da un factor de aceleración de 1.0/0.8 = 1.25 o 25 %

Entonces, ¿cómo se encuentran esas líneas? This is the method I use. Nadie dice que es bonita, a menos que se aprecien los resultados totales. Si se aplica repetidamente, large speedup factors are possible.

Answer 2

Según mi experiencia, es probable que esté en el GC. Si usas LINQ, es casi seguro que esté en el GC. Recomiendo CLRProfiler para rastrear Gen 0 spam.