2008-09-28 14 views
6

Necesito hacer algunos benchmarks de rendimiento en programas .NET (C#) en Windows, pero no he hecho benchmarking mucho en el mundo de Windows. He buscado utilizar el monitor de rendimiento de Windows 2000/XP con contadores personalizados para esto, pero no creo que esto sea exactamente lo que quiero.¿Cuál es la mejor manera de comparar programas en Windows?

¿Hay alguna buena instalación de sistema para esto en Windows XP, o solo necesito usar System.Diagnostics.Stopwatch [edit] y escribir registros de texto para la interpretación manual, o hay algo más?

Editar: ¿hay algo más allá de System.Diagnostics.Stopwatch?

+0

para que otras personas puedan beneficiarse de respuestas adicionales, creo que sería mejor para usted para reabrir la pregunta. –

+0

Aggh, otra lección de paralelismo que salió mal ... –

+0

@Michael Ratanapintha: ¿te importa elaborar? –

Respuesta

5

Para micro-benchmarking Me gusta mucho MeasureIt (se puede descargar desde http://msdn.microsoft.com/en-us/magazine/cc500596.aspx). Es un proyecto de prueba escrito por Vance Morrison, un arquitecto de rendimiento en el CLR. Actualmente tiene un buen conjunto de puntos de referencia para varios métodos centrales de .Net/CLR. La mejor parte es que es trivial modificar y agregar nuevos puntos de referencia para lo que quieras probar. Simplemente ejecute "MeasureIt/edit" e iniciará VS con el proyecto por sí mismo para que pueda ver cómo se escriben esos puntos de referencia y agregar nuevos de manera similar si lo desea.

Como ya se ha indicado, el cronómetro es probablemente la forma más fácil de hacerlo y MeasureIt usa el cronómetro debajo para sus tiempos, pero también hace otras cosas como ejecutar un bloque de código X veces y luego proporcionar estadísticas para las carreras y qué no.

8
using System.Diagnostics; 
.... 

Stopwatch sw = new Stopwatch(); 

sw.Start(); 

// Code you want to time... 

// Note: for averaged accuracy (without other OS effects), 
//  run timed code multiple times in a loop 
//  and then divide by the number of runs. 

sw.Stop(); 

Console.WriteLine("Took " + sw.ElapsedTicks + " Ticks"); 
+0

También debe separar la primera ejecución de los resultados promediados, ya que puede estar muy sesgada debido al proceso de compilación de JIT. –

+0

Ed. S: Buen punto, pero no necesariamente. Si el código solo se ejecuta una vez en la realidad, entonces el tiempo JIT probablemente deba incluirse en. –

+1

Claro, no quise ignorar esa información por completo, solo para asegurarme de segregarla para que no aumente la velocidad. promedio arriba. Mientras la persona que hace la prueba esté al tanto de este hecho, debería estar bien. Estaba retocando una rutina de análisis XML que se puede invocar en algunos pedazos de datos bastante grandes (en relación con lo que es típico en mi aplicación de todos modos) y el primer pase tomó ~ 931 ms, mientras que todas las llamadas posteriores tomaron ~ 91 ms. –

3

esto puede no ser lo que quiera, pero dotTrace ofrece muchos diagnósticos útiles y está integrado en Visual Studio.

4

Hay bastantes perfiladores por ahí. Éstos son algunos de los que yo conozco:

Si vas de con el uso de System.Diagnostics.Stopwatch, usted será capaz de instrumentos y mida solo puntos particulares de su código, donde pone explícitamente el Start/Stop. Esto es lo suficientemente bueno para medir piezas específicas, como un ciclo cerrado o cosas por el estilo, pero no le dará una idea completa de dónde pasa su programa la mayor parte del tiempo.

4

Si solo desea números rápidos, puede usar Powershell para cronometrar la ejecución general. Use el cmdlet measure-command. Es más o menos equivalente a "tiempo" en Unix.

> measure-command { your.exe arg1 } 

Days    : 0 
Hours    : 0 
Minutes   : 0 
Seconds   : 4 
Milliseconds  : 996 
Ticks    : 49963029 
TotalDays   : 5.78275798611111E-05 
TotalHours  : 0.00138786191666667 
TotalMinutes  : 0.083271715 
TotalSeconds  : 4.9963029 
TotalMilliseconds : 4996.3029 
Cuestiones relacionadas