Visualización de las marcas de tiempo en una pila de llamadas

Question

Estoy tratando de ajustar el rendimiento de mi aplicación. Y tengo curiosidad por saber qué métodos están tardando más en procesarse y, por lo tanto, se deben buscar oportunidades de optimización.

¿Existen herramientas gratuitas existentes que me ayuden a visualizar la pila de llamadas y cuánto tiempo tarda cada método en completarse? Estoy pensando en algo que muestra la pila de llamadas como un gráfico de barras apiladas o un treemap por lo que es es fácil ver que el Método A () tardó 10 segundos en completarse porque llamó al Método B () y al Método (C) que tardó 3 y 7 segundos para completar.

¿Existe algo como esto?

Answer 1

Sí, se llaman perfiladores de rendimiento. Echa un vistazo a RedGate ANTS y ??el dotTrace de JetBrains, no gratis pero bastante barato y mucho mejor que cualquier otra alternativa gratuita que haya visto.

Answer 2

Hay varios perfiladores disponibles. Solo estoy familiarizado con uno (el incluido en Visual Studio Team Suite), pero no es gratis. Debo decir que ha sido lo suficientemente potente / confiable como para no haber deseado intentar cambiarme a otro. El otro del que he oído hablar es el perfilador .NET de Red Gate (tampoco gratuito). Ambos tienen conjuntos de características que incluyen, entre otros, lo que buscas. Si esto es para el desarrollo de aplicaciones comerciales, definitivamente échales un vistazo. :)

Answer 3

La forma en que esto se mide es mediante instrumentación o muestreo dentro de un generador de perfiles.

Instrumentación

La instrumentación hace el equivalente aproximado de reescribir todo su código para hacer lo siguiente:

public void Foo()
{
   //Code
}

en

public void Foo()
{
   InformTheProfilingCodeThatFooStarted();
   //Code
   InformTheProfilingCodeThatFooEnded();
}

Dado que el generador de perfiles sabe cuándo todo comienza y se detiene, puede administrar una pila de cuándo comienza y se detiene esto, y proporciona esta información más tarde. Muchos le permiten hacer esto a nivel de línea (haciendo lo mismo pero instrumentando aún más antes de cada línea.

Esto obtiene su información 100% precisa sobre el 'gráfico de llamadas' en su aplicación, pero lo hace a costa de: evitar la incorporación de métodos y agregar una sobrecarga considerable a cada llamada a métodos.

Muestreo

Un enfoque alternativo es el muestreo.

En lugar de tratar de obtener gráficos de llamadas 100% precisos, pero con veces reales menos que precisas, este enfoque funciona en función de que, si verifica regularmente lo que sucede en su aplicación puede darte una buena idea de cuánto tiempo pasa en varias funciones sin tener que gastar mucho esfuerzo en resolver esto. La mayoría de los perfiladores de muestreo saben cómo "analizar" la pila de llamadas cuando interrumpen el programa para que puedan dar una idea razonable de lo que está llamando qué función y cuánto tiempo parece tomar, pero no podrán decirle si esto fue (digamos) 10 llamadas a Foo () que hicieron diez llamadas a Bar () o una llamada a Foo () que estaba en la única llamada a Bar () que solo duró 10 veces.

Ambos enfoques tienen sus pros y sus contras y resuelven diferentes problemas. En general, el método de muestreo es el mejor para comenzar, ya que es menos invasivo y, por lo tanto, debe proporcionar información más precisa sobre lo que toma tiempo , que a menudo es la primera pregunta más importante antes de resolver por qué .

Conozco solo un perfilador de muestreo gratuito para el código .net que es el perfilador redistribuible gratuito que está vinculado con la versión VS 2008 Team System (pero que se puede descargar por separado). El resultado resultante no se puede ver fácilmente con nada más que la edición (muy costosa) Team System de Visual Studio.

Red Gate ANTS no admite muestreo (en este momento), Jet Brains (dotTrace) y MS Visual Studio Team System tienen perfiladores que admiten ambos estilos. Lo que prefiera en función del costo beneficio es una cuestión de opinión.

Answer 4

Este es el método I use. Si tiene un IDE con un botón de pausa, no cuesta nada y funciona muy bien.

Lo que te dice es aproximadamente qué porcentaje del tiempo de reloj de pared se gasta en cada rutina, y más precisamente, en cada declaración. Eso es más importante que la duración promedio de ejecución de la rutina o declaración, ya que automáticamente tiene en cuenta el recuento de invocación. Al muestrear el tiempo del reloj de pared, incluye automáticamente CPU, IO y otros tipos de tiempo del sistema.

Aún más importante, si observa las muestras en las que su rutina está en la pila de llamadas, puede ver no solo lo que está haciendo, sino también por qué . La razón por la que es importante es que lo que realmente está buscando es tiempo que se podría reemplazar por algo más rápido. Sin el " por qué " información, tienes que adivinar qué es eso.

Por cierto: esta técnica es poco conocida principalmente porque los profesores no la enseñan (incluso si la conocen) porque rara vez tienen que trabajar con software monstruoso como el que tenemos en el mundo real, por lo que tratan gprof como el paradigma básico de la creación de perfiles.

Aquí hay un ejemplo de cómo usarlo.

P.S. Espere que los porcentajes sumen mucho más del 100%. La forma de pensar sobre los porcentajes es, si una declaración o rutina está en la pila X% del tiempo (como se estima a partir de un pequeño número de muestras), eso es aproximadamente cuánto tiempo de reloj de pared se reducirá si la declaración o rutina se puede hacer que tome mucho menos tiempo.