c# - tablas - ¿Cuál es la mejor manera de medir cuánto tiempo tarda el código en ejecutarse?

porque se dañan las tablas en mysql

Question

Estoy tratando de determinar qué enfoque para eliminar una cadena es el más rápido .

Simplemente obtengo la hora de inicio y finalización y muestro la diferencia.

Pero los resultados son muy variados , por ejemplo, como se muestra a continuación, el mismo método puede tomar de 60 ms a 231 ms.

¿Cuál es un mejor método para obtener resultados más precisos?

texto alternativo http://www.deviantsart.com/upload/1q4t3rl.png

using System;
using System.Collections;
using System.Collections.Generic;
namespace TestRemoveFast
{
class Program
{
static void Main(string[] args)
{
for (int j = 0; j < 10; j++)
{
string newone = "";
List<string> tests = new List<string>();
for (int i = 0; i < 100000; i++)
{
tests.Add("{http://company.com/Services/Types}ModifiedAt");
}
DateTime start = DateTime.Now;
foreach (var test in tests)
{
//newone = ((System.Xml.Linq.XName)"{http://company.com/Services/Types}ModifiedAt").LocalName;
newone = Clean(test);
}
Console.WriteLine(newone);
DateTime end = DateTime.Now;
TimeSpan duration = end - start;
Console.WriteLine(duration.ToString());
}
Console.ReadLine();
}
static string Clean(string line)
{
int pos = line.LastIndexOf(''}'');
if (pos > 0)
return line.Substring(pos + 1, line.Length - pos - 1);
//return line.Substring(pos + 1);
else
return line;
}
}
}

Answer 1

Debe utilizar System.Diagnostics.Stopwatch , y es posible que desee considerar una muestra grande. Por ejemplo, repita esta prueba aproximadamente 10,000 veces y promedie los resultados. Si lo piensas científicamente, tiene sentido. Cuanto mayor sea la muestra, mejor. Puede eliminar muchos casos extremos de esta manera y realmente ver cómo es el rendimiento central.

Otra cosa a considerar es que la compilación de JIT y la creación de objetos definitivamente pueden sesgar los resultados, así que asegúrese de iniciar y detener su cronómetro en los momentos apropiados, y llame a los métodos que quiera probar al menos una vez antes de comenzar las pruebas. Intente segregar tanto como sea posible las partes que desea probar del resto de su código.

Answer 2

El problema con todos los enfoques basados ​​en reloj es que nunca está seguro de lo que está cronometrando. Puede, ya sea que se dé cuenta o no, incluir en su tiempo:

• demora mientras el o / s adelanta su procesador;
• cambio de contexto
• se para mientras el programa espera datos;
• y mucho, mucho más.

No estoy diciendo que todos estos se apliquen a este tiempo en particular, sino a los tiempos en general. Por lo tanto, debe complementar cualquier momento que tenga con alguna consideración de cuántas operaciones básicas ejecutan sus códigos alternativos, algunas consideraciones de complejidad que no ignoran (como solemos hacer) los términos constantes.

En su caso particular, debe tratar de programar ejecuciones mucho más largas; cuando tus tiempos son inferiores a los segundos, es muy probable que el o / s te moleste. Por lo tanto, ejecute 10 ^ 6 iteraciones y use el promedio en las corridas suficientes para obtener un cálculo significativo del promedio y la varianza. Y asegúrese, si toma este enfoque, de que no acelere inadvertidamente la segunda prueba teniendo los datos ya cargados después del final de la primera prueba. Debe asegurarse de que cada uno de los 10 ^ 6 ensayos haga exactamente lo que hace el primer ensayo.

Que te diviertas

marca

Answer 3

Generalmente: no mire el tiempo de reloj de pared sino el tiempo de CPU consumido por su proceso para determinar cuánto tiempo funcionó. Especialmente para cosas que son solo computación, esto es mucho más confiable porque no se verá afectado por otros procesos que se ejecutan al mismo tiempo.

Answer 4

Hay mucha actividad bajo el capó del sistema operativo, que es muy probable que estropee sus mediciones de tiempo. Con el fin de mejorar la precisión de los tiempos medidos, debe ejecutar las pruebas varias veces y eliminar el más bajo y el mayor de los resultados finales. Este enfoque excluirá la mayoría de los factores externos que pueden influir en el tiempo de ejecución de su código y le servirá bien en la mayoría de los casos. La clase System.Diagnostics.Stopwatch se usa para medir el tiempo, ya que es mucho más preciso que utilizar DateTime .

Puede hacer fácilmente una clase de prueba para automatizar esto. He publicado una de esas clases en mi blog . Puede comparar el rendimiento de dos fragmentos / algoritmos de código C #. Todo lo que tiene que hacer es anular los métodos Method1 y Method2 poniendo allí los fragmentos de código que desea probar y usar la clase de prueba de esta manera:

Test test = new CustomTest();
Console.WriteLine("/n==============================");
Console.WriteLine(test.Execute());
Console.WriteLine("==============================/n");

Answer 5

Puede que tenga que aplicar algunas técnicas estadísticas aquí para resolver la varianza. Intente ejecutar el mismo fragmento de código 1000 veces y luego tome el tiempo promedio, y compare eso. Las simulaciones generalmente emplean algún tipo de método para ''limpiar'' los números, y este es uno de esos.

Answer 6

Puedes usar la clase System.Diagnostics.Stopwatch .

El cronómetro mide el tiempo transcurrido contando las marcas del temporizador en el mecanismo del temporizador subyacente. Si el hardware y el sistema operativo instalados admiten un contador de rendimiento de alta resolución, la clase Cronómetro usa ese contador para medir el tiempo transcurrido.

var sw = new Stopwatch();
sw.Start();
// ...
sw.Stop();

Answer 7

Si solo está preocupado por probarlo en su propio código ... use un System.Diagnostics.Stopwatch

Por lo general, prefiero romper este tipo de cosas fuera de mi código y usar un verdadero Profiler como RedGate''s Performance Profiler

Answer 8

Tendré que recomendar el mejor perfil incluido en Visual Studio Team Suite o Development Edition (o el próximo Visual Studio 2010 Premium o Ultimate es aún mejor) como la mejor manera. Es altamente configurable, extremadamente potente, fácil de usar, muy rápido y funciona tanto con código nativo como con código administrado. No estoy familiarizado con el flujo de trabajo de ANTS , pero parece ser otra opción. Sin duda, el uso de un generador de perfiles es la única opción para un desarrollador que se preocupa por el rendimiento de su aplicación. No hay sustituto, y realmente no se puede tomar a ningún desarrollador comercial que trabaje en el rendimiento que deje pasar un perfilador en serio.

Sin embargo, si le interesan las medidas para uno de los siguientes, es posible que no tenga acceso a dicho generador de perfiles, en cuyo caso la clase Cronómetro puede formar una base para su técnica de medición:

• Un estudiante o aficionado interesado en la ejecución de sus proyectos (un perfilador comercial puede estar fuera de su alcance por razones financieras)
• En una aplicación lanzada al público, es posible que desee cronometrar las secciones de código que se ejecutan en el subproceso de IU e informar las estadísticas para asegurarse de que las operaciones nunca causen demoras notables para ninguno de sus usuarios. El equipo de Office utilizó un método como este con enorme éxito (¿alguien de Outlook 2007 SP2?), Y sé que el equipo de Visual Studio tiene este código al menos en la versión de 2010.

Answer 9

Tres notas simples:

1. Use System.Diagnostics.Stopwatch .

2. No perfile su código en la misma entrada un millón de veces. Intenta encontrar tu distribución esperada de entradas y perfil sobre eso. Ese es el perfil de la entrada en el mundo real, no la entrada de laboratorio.

3. Ejecute el método Clean una vez antes de ingresar al ciclo de creación de perfiles para eliminar el tiempo de JITting. A veces esto es importante.

De estos, los apuntes 1. y 2. son de lejos los más importantes.

Sus resultados de generación de perfiles no tienen sentido si no está usando un temporizador de alta resolución. Tenga en cuenta que no tenemos tiempo para usar Usain Bolt con un reloj de agua .

Sus resultados de creación de perfiles no tienen sentido si no está probando en el mundo real. Tenga en cuenta que las pruebas de choque estrellan los autos en otros autos a 35 MPH, no en las paredes hechas de marshmellows a 5 MPH.

Así:

// expectedInput is string[1000000]
// populate expectedInput with real-world input
Clean(expectedInput[0]);
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 1000000; i++) {
string t = Clean(expectedInput[i]);
}
sw.Stop();
Console.WriteLine(sw.Elapsed);

Una nota compleja:

Si realmente necesita hacer perfiles, obtenga un generador de perfiles como ANTS .