La mejor manera de medir la velocidad de las funciones, clases y procesos

Question

¿Cuál es la mejor manera de medir la velocidad de las funciones y clases? Para cada función hay varias soluciones y me gustaría saber cómo medir la velocidad de ejecución y optimizar mis clases compartidas con la mejor solución posible.

Además, ¿cómo se mide la velocidad de SQL, por ejemplo, diferencias entre los procedimientos almacenados, seleccionar, vistas, etc.?

Answer 1

Tienes dos opciones.

Usar System.Diagnostics.Stopwatch para métodos específicos.

Este es un temporizador de alta resolución en .NET que puede usar para partes específicas de su código.

Use un Profiler si necesita medir el rendimiento para toda su aplicación.

Puede usar la construcción de perfiladores de la edición Ultra de Visual Studio, o una herramienta como Eqatec.

Answer 2

Es mejor usar un perfilador. El problema con la medición del tiempo de ejecución de la luz de pared (como el hecho de la Stopwatch La clase) es que está influenciado por muchos factores lejos de su control. Para mencionar solo algunos factores de estos, hay una red y otros latencia de E/S, y decisiones del programador del sistema operativo que influyen en la prioridad relativa de las aplicaciones y los hilos. Si está ejecutando dentro de un entorno virtualizado, eso también puede tener un efecto relativamente grande en las mediciones de tiempo de la pared de rango de milisegundos. El Profiler no será perfecto, pero le dará una mejor idea de cuánto tiempo se dedica realmente a ejecutar su código.

Además de eso, un buen perfilador a menudo también puede brindarle otras métricas útiles, como cuánta memoria usa su código durante la ejecución.

Answer 3

Es mejor no confundir los objetivos de medir y optimizar. Son tareas diferentes. Medir, aunque bueno para cuantificar los resultados de arreglar algo, es pobre para decirle qué arreglar.

Sobre el tema de la medición, si quiero hacer una presentación de lo rápido que es algo, quiero un entorno controlado y un buen cronómetro. Sin embargo, con el propósito de optimizar, las mediciones crudas (como ejecutar algo 1000 veces) y usar un temporizador simple, son más que buenas.

Sobre el tema de la optimización, no me preocupa la velocidad. Me preocupa la actividad innecesaria. No es necesario ejecutar el código a alta velocidad para encontrarlo.

Cuando se ejecuta cualquier programa, traza un árbol de llamadas. La optimización consiste en eliminar la mayor cantidad de hojas (instrucciones) y la mayor cantidad de fruta (E/S) como sea posible. Una buena manera de hacer esto es podar ramas enteras.

• En todos menos los programas más pequeños, las oportunidades típicas para la optimización consisten en puntos de llamada (líneas de código donde se llaman funciones, no las funciones en sí) que, cuando uno se da cuenta de cuánto del árbol de llamadas brota de ellas, realmente se podría hacer otra camino. Una sola línea de código de aspecto inocente podría ser responsable de una gran fracción de todo el árbol, y es posible que pueda simplemente cortarlo.

Para encontrarlos, creo que el muestreo de la pila de tiempo de pared de pared es la mejor manera. No es necesario que este sea un proceso eficiente, y un número bastante pequeño de muestras funciona igual de bien (o mejor) que una gran cantidad de muestras. Es necesario hacerlo repetidamente, porque cualquier programa determinado, como se escribió por primera vez, no contiene una sola oportunidad de acelerar. Contiene varios.Aquí hay un ejemplo.