2010-09-22 9 views
6

algunas partes de mi programa son muy lentas. y me preguntaba si hay alguna herramienta que pueda usar y, por ejemplo, me puede decir que ejecutar OKA() tomó 100ms, etc ... o información tan útil similar a eso.¿Alguna herramienta que indique cuánto tarda cada método en ejecutarse?

+3

Se llama [Profiler] (http://stackoverflow.com/search?q= [c% 23] + profiler). – dtb

+1

Lo que estás buscando se llama perfilador. – GrandmasterB

+2

posible duplicado de [¿Qué son algunos buenos perfiladores .NET?] (Http://stackoverflow.com/questions/3927/what-are-some-good-net-profilers) – dtb

Respuesta

8

El espacio de nombres System.Diagnostics ofrece una clase útil llamada Stopwatch, que se puede utilizar para medir el tiempo de partes de su código (piénselo como un "generador de perfiles de un pobre").

Esta es la forma en que lo utilizaría:

Stopwatch stopwatch = new Stopwatch(); 
stopwatch.Start(); // Start timing 

// This is what we want to time 
DoSomethingWeSuspectIsSlow(); 

stopwatch.Stop(); 
Console.WriteLine("It took {0} ms.", stopwatch.ElapsedMilliseconds); 
+3

o, crea una clase que implementa idisposable, que inicia el temporizador en contruction, se detiene y escribe en dispose. ¡Entonces puede medir el tiempo de cualquier bloque de código envolviéndolo con una instrucción de uso! –

+1

También asegúrese de que el método haya sido invocado al menos una vez antes de cronometrarlo, para que no mida el tiempo de compilación JIT. –

+0

@John Gardner: su construcción también es útil para obtener tiempos de perfunción de un sistema Prod en ejecución. Acumule los tiempos para las partes del elemento de trabajo con una etiqueta que los identifique y vacíe al final del elemento de trabajo. –

3

Ese tipo de aplicaciones son conocidos como "perfiladores"

Aquí hay uno, por ejemplo: example

12

Si está utilizando Visual Studio Team System no es un generador de perfiles incorporado en 'Herramientas de rendimiento. Hay un montón de antecedentes útiles sobre esto en this blog.

He encontrado esto extremadamente útil para identificar el 20% of my code that runs 80% of the time, y de ahí lo que debería preocuparme por optimizar.

Otra técnica simple que puede ser sorprendentemente efectiva es ejecutar su código de liberación en el depurador, e interrumpirlo unas cuantas veces (10 o más pueden ser suficientes) mientras está en el estado 'ocupado' que está tratando de diagnosticar . Puede encontrar información de pila de llamadas recurrente que lo dirige al área general de preocupación. Nuevamente, la regla 80/20 en vigencia.

+1

+1 He estado usando ese método de interrupción desde antes de que se concibieran los perfiladores. Me desconcertó que tan poca gente lo supiera. Yo diría que realmente identifica el área de preocupación, y la regla 80/20 es más como 99.9/0.1 –

+0

Lamentablemente, ese enlace 80/20 es particularmente vacío. –

+0

@Mike Dunlavey - ¿tienes uno mejor? Editaré en si es así. Gracias –

2

Ver nuestra SD C# Profiler. Puede proporcionar los tiempos de función de la función por sí mismo y/o todas sus calles.

Cuestiones relacionadas