Puede utilizar el enfoque descrito aquí http://www.codeproject.com/KB/dotnet/ExecutionStopwatch.aspx que utiliza GetThreadTimes función del sistema http://msdn.microsoft.com/en-us/library/ms683237(v=vs.85).aspx
tiempo de espera es la diferencia entre el tiempo total y el tiempo de ejecución.
Agregado: me gusta usar la clase desechable para medir el rendimiento - que mantiene un código limpio (uso de la consola hardcoded sólo por ejemplo):
public class ThreadPerformance : IDisposable
{
private Stopwatch _totalStopwatch = new Stopwatch();
private ExecutionStopwatch _executionStopwatch = new ExecutionStopwatch();
public static ThreadPerformance Measure()
{
return new ThreadPerformance();
}
private ThreadPerformance()
{
_totalStopwatch.Start();
_executionStopwatch.Start();
}
public void Dispose()
{
_executionStopwatch.Stop();
_totalStopwatch.Stop();
Console.WriteLine("Performance mesurement for thread {0}", Thread.CurrentThread.ManagedThreadId);
Console.WriteLine("Waiting: {0}", _totalStopwatch.Elapsed - _executionStopwatch.Elapsed);
Console.WriteLine("CPU usage: {0}", _executionStopwatch.Elapsed);
}
}
uso es muy sencillo:
static void ThreadProc()
{
using (ThreadPerformance.Measure())
{
// do some calculations and waitings here
}
}
Gracias lazyberezovsky. Estaba pensando en la misma línea. No estoy seguro de si esta solución funcionará sin ningún problema en diferentes plataformas de sistema operativo/versiones .NET/plataformas de hardware. La documentación de Microsoft no ofrece ninguna garantía de que el hilo administrado .NET siempre se correlacione con el mismo subproceso no administrado. ¿Qué ocurre si GetCurrentThread() devuelve diferentes identificadores de subprocesos en dos llamadas separadas? – Nitin