¿Cómo se prueba el rendimiento del código JavaScript?

Ciclos de CPU, uso de memoria, tiempo de ejecución, etc.

Agregado: ¿Existe una forma cuantitativa de probar el rendimiento en JavaScript además de la percepción de la rapidez con que se ejecuta el código?

Los perfiladores son definitivamente una buena manera de obtener números, pero en mi experiencia, el rendimiento percibido es todo lo que le importa al usuario / cliente. Por ejemplo, tuvimos un proyecto con un acordeón Ext que se expandió para mostrar algunos datos y luego algunas cuadrículas Ext anidadas. En realidad, todo se estaba procesando bastante rápido, ninguna operación sola tomó mucho tiempo, solo se procesó mucha información a la vez, por lo que el usuario se sintió lento.

"Arreglamos" esto, no cambiando a un componente más rápido u optimizando algún método, sino representando primero los datos y luego representando las cuadrículas con setTimeout. Entonces, la información apareció primero, luego las cuadrículas aparecerían en su lugar un segundo después. En general, tomó un poco más de tiempo de procesamiento hacerlo de esa manera, pero para el usuario, el rendimiento percibido mejoró.

En estos días, el perfilador Chrome y otras herramientas son universalmente disponibles y fáciles de usar, como son console.time(), console.profile()y performance.now(). Chrome también le brinda una vista de línea de tiempo que puede mostrarle qué está matando su velocidad de cuadros, dónde podría estar esperando el usuario, etc.

Encontrar documentación para todas estas herramientas es realmente fácil, no necesita una respuesta SO para eso. 7 años después, seguiré repitiendo el consejo de mi respuesta original y señalaré que puede ejecutar código lento para siempre donde un usuario no lo notará, y ejecutar código bastante rápido donde lo hace, y se quejarán sobre el el código bastante rápido no es lo suficientemente rápido. O que su solicitud a la API de su servidor tomó 220 ms. O algo más como eso. El punto sigue siendo que si saca un generador de perfiles y busca trabajo que hacer, lo encontrará, pero puede que no sea el trabajo que necesitan sus usuarios.

Estoy de acuerdo en que el rendimiento percibido es realmente todo lo que importa. Pero a veces solo quiero averiguar qué método de hacer algo es más rápido. A veces la diferencia es ENORME y vale la pena conocerla.

Podrías simplemente usar temporizadores de JavaScript. Pero típicamente obtengo resultados mucho más consistentes usando los métodos devTool console.time()y Chrome nativos de Chrome (ahora también en Firefox y Safari)console.timeEnd()

Ejemplo de cómo lo uso:

var iterations = 1000000;
console.time('Function #1');
for(var i = 0; i < iterations; i++ ){
    functionOne();
};
console.timeEnd('Function #1')

console.time('Function #2');
for(var i = 0; i < iterations; i++ ){
    functionTwo();
};
console.timeEnd('Function #2')

Actualización (4/4/2016):

Chrome canary agregó recientemente el perfil de nivel de línea en la pestaña de fuentes de herramientas de desarrollo que le permite ver exactamente cuánto tiempo tardó en ejecutarse cada línea.

Siempre podemos medir el tiempo que toma cualquier función mediante un simple objeto de fecha .

var start = +new Date();  // log start timestamp
function1();
var end =  +new Date();  // log end timestamp
var diff = end - start;

Prueba jsPerf . Es una herramienta de rendimiento de JavaScript en línea para comparar y comparar fragmentos de código. Lo uso todo el tiempo.

La mayoría de los navegadores ahora están implementando el tiempo de alta resolución performance.now(). Es superior a new Date()las pruebas de rendimiento porque funciona independientemente del reloj del sistema.

Uso

var start = performance.now();

// code being timed...

var duration = performance.now() - start;

Referencias

• https://developer.mozilla.org/en-US/docs/Web/API/Performance.now ()
• http://www.w3.org/TR/hr-time/#dom-performance-now

JSLitmus es una herramienta ligera para crear pruebas de referencia JavaScript ad-hoc

Vamos a examinar el rendimiento entre function expressiony function constructor:

<script src="JSLitmus.js"></script>
<script>

JSLitmus.test("new Function ... ", function() { 
    return new Function("for(var i=0; i<100; i++) {}"); 
});

JSLitmus.test("function() ...", function() { 
       return (function() { for(var i=0; i<100; i++) {}  });
});

</script>

Lo que hice arriba es crear una function expressiony function constructorrealizar la misma operación. El resultado es el siguiente:

Resultado de rendimiento de FireFox

Resultado de rendimiento de IE

Algunas personas sugieren complementos y / o navegadores específicos. No lo haría porque solo son realmente útiles para esa plataforma; una prueba ejecutada en Firefox no se traducirá con precisión a IE7. Teniendo en cuenta que el 99.999999% de los sitios tienen más de un navegador que los visita, debe verificar el rendimiento en todas las plataformas populares.

Mi sugerencia sería mantener esto en el JS. Cree una página de evaluación comparativa con todas sus pruebas de JS y programe la ejecución. Incluso podría hacer que AJAX publique los resultados para mantenerlo completamente automatizado.

Luego solo enjuague y repita sobre diferentes plataformas.

Tengo una pequeña herramienta donde puedo ejecutar rápidamente pequeños casos de prueba en el navegador e inmediatamente obtener los resultados:

Prueba de velocidad de JavaScript

Puedes jugar con el código y descubrir qué técnica es mejor en el navegador probado.

Creo que las pruebas de rendimiento (tiempo) de JavaScript son suficientes. Encontré un artículo muy útil sobre las pruebas de rendimiento de JavaScript aquí .

Aquí hay una función simple que muestra el tiempo de ejecución de una función pasada:

var perf = function(testName, fn) {
    var startTime = new Date().getTime();
    fn();
    var endTime = new Date().getTime();
    console.log(testName + ": " + (endTime - startTime) + "ms");
}

Puede usar esto: http://getfirebug.com/js.html . Tiene un generador de perfiles para JavaScript.

Respuesta rápida

En jQuery (más específicamente en Sizzle), usamos esto (checkout master y open speed / index.html en su navegador), que a su vez usa benchmark.js . Esto se utiliza para probar el rendimiento de la biblioteca.

Respuesta larga

Si el lector no conoce la diferencia entre el punto de referencia, la carga de trabajo y los perfiladores, primero lea algunos fundamentos de las pruebas de rendimiento en la sección "readme 1st" de spec.org . Esto es para las pruebas del sistema, pero comprender estos fundamentos también ayudará a las pruebas JS perf. Algunos puntos destacados:

¿Qué es un punto de referencia?

Un punto de referencia es "un estándar de medición o evaluación" (Diccionario Webster's II). Un punto de referencia informático suele ser un programa informático que realiza un conjunto de operaciones estrictamente definido, una carga de trabajo, y devuelve alguna forma de resultado, una métrica, que describe cómo se desempeñó la computadora probada. Las métricas de referencia de la computadora generalmente miden la velocidad: qué tan rápido se completó la carga de trabajo; o rendimiento: cuántas unidades de carga de trabajo por unidad de tiempo se completaron. Ejecutar el mismo punto de referencia de computadora en varias computadoras permite hacer una comparación.

¿Debo comparar mi propia aplicación?

Idealmente, la mejor prueba de comparación para sistemas sería su propia aplicación con su propia carga de trabajo. Desafortunadamente, a menudo no es práctico obtener una amplia base de mediciones confiables, repetibles y comparables para diferentes sistemas utilizando su propia aplicación con su propia carga de trabajo. Los problemas pueden incluir la generación de un buen caso de prueba, problemas de confidencialidad, dificultad para garantizar condiciones comparables, tiempo, dinero u otras restricciones.

Si no es mi propia aplicación, ¿entonces qué?

Es posible que desee considerar el uso de puntos de referencia estandarizados como punto de referencia. Idealmente, un punto de referencia estandarizado será portátil y puede que ya se haya ejecutado en las plataformas que le interesan. Sin embargo, antes de considerar los resultados, debe asegurarse de comprender la correlación entre sus necesidades de aplicación / computación y cuáles son El punto de referencia está midiendo. ¿Son los puntos de referencia similares a los tipos de aplicaciones que ejecuta? ¿Las cargas de trabajo tienen características similares? Según sus respuestas a estas preguntas, puede comenzar a ver cómo el punto de referencia puede aproximarse a su realidad.

Nota: Un punto de referencia estandarizado puede servir como punto de referencia. Sin embargo, cuando realiza una selección de proveedor o producto, SPEC no afirma que ningún punto de referencia estandarizado pueda reemplazar la evaluación comparativa de su propia aplicación real.

Pruebas de rendimiento JS

Idealmente, la mejor prueba de rendimiento sería usar su propia aplicación con su propia carga de trabajo cambiando lo que necesita probar: diferentes bibliotecas, máquinas, etc.

Si esto no es factible (y generalmente no lo es). El primer paso importante: define tu carga de trabajo. Debe reflejar la carga de trabajo de su aplicación. En esta charla , Vyacheslav Egorov habla sobre cargas de trabajo de mierda que debes evitar.

Luego, puede usar herramientas como benchmark.js para ayudarlo a recopilar métricas, generalmente la velocidad o el rendimiento. En Sizzle, estamos interesados ​​en comparar cómo las correcciones o cambios afectan el rendimiento sistémico de la biblioteca.

Si algo funciona realmente mal, su próximo paso es buscar cuellos de botella.

¿Cómo encuentro cuellos de botella? Perfiladores

¿Cuál es la mejor manera de perfilar la ejecución de JavaScript?

Creo que el tiempo de ejecución es la mejor medida.

Se podría utilizar console.profile en Firebug

Por lo general, solo pruebo el rendimiento de JavaScript, cuánto tiempo se ejecuta el script. jQuery Lover dio un buen enlace de artículo para probar el rendimiento del código de JavaScript , pero el artículo solo muestra cómo probar cuánto tiempo se ejecuta su código de JavaScript. También recomendaría leer el artículo llamado "5 consejos para mejorar su código jQuery mientras trabaja con grandes conjuntos de datos".

Aquí hay una clase reutilizable para el rendimiento del tiempo. El ejemplo está incluido en el código:

/*
     Help track time lapse - tells you the time difference between each "check()" and since the "start()"

 */
var TimeCapture = function () {
    var start = new Date().getTime();
    var last = start;
    var now = start;
    this.start = function () {
        start = new Date().getTime();
    };
    this.check = function (message) {
        now = (new Date().getTime());
        console.log(message, 'START:', now - start, 'LAST:', now - last);
        last = now;
    };
};

//Example:
var time = new TimeCapture();
//begin tracking time
time.start();
//...do stuff
time.check('say something here')//look at your console for output
//..do more stuff
time.check('say something else')//look at your console for output
//..do more stuff
time.check('say something else one more time')//look at your console for output

UX Profiler aborda este problema desde la perspectiva del usuario. Agrupa todos los eventos del navegador, la actividad de la red, etc. causados ​​por alguna acción del usuario (clic) y tiene en cuenta todos los aspectos como la latencia, los tiempos de espera, etc.

Estaba buscando algo similar pero encontré esto.

https://jsbench.me/

Permite una comparación de lado a lado y luego también puede compartir los resultados.

La regla de oro es NO bloquear bajo ninguna circunstancia el navegador de su usuario. Después de eso, generalmente miro el tiempo de ejecución, seguido del uso de memoria (a menos que esté haciendo algo loco, en cuyo caso podría ser una prioridad más alta).

Las pruebas de rendimiento se convirtieron en una palabra de moda en los últimos tiempos, pero eso no quiere decir que las pruebas de rendimiento no sean un proceso importante en el control de calidad o incluso después de que se haya enviado el producto. Y mientras desarrollo la aplicación, utilizo muchas herramientas diferentes, algunas de ellas mencionadas anteriormente, como el Chrome Profiler , generalmente miro un SaaS o algo de código abierto que puedo poner en marcha y lo olvido hasta que recibo esa alerta que dice que algo se vino abajo. .

Hay muchas herramientas increíbles que lo ayudarán a controlar el rendimiento sin tener que saltar por los aros solo para configurar algunas alertas básicas. Aquí hay algunos que creo que vale la pena echarle un vistazo.

1. Sematext.com
2. Datadog.com
3. Uptime.com
4. Smartbear.com
5. Solarwinds.com

Para tratar de pintar una imagen más clara, aquí hay un pequeño tutorial sobre cómo configurar el monitoreo para una aplicación de reacción.

Esta es una buena forma de recopilar información de rendimiento para la operación específica.

start = new Date().getTime(); 
for (var n = 0; n < maxCount; n++) {
/* perform the operation to be measured *//
}
elapsed = new Date().getTime() - start;
assert(true,"Measured time: " + elapsed);