llamar insertar ejemplos desde cómo codigo javascript performance

insertar - javascript en html ejemplos



¿Cómo pruebas de rendimiento el código JavaScript? (19)

¿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 qué tan rápido corre el código?


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 toda su prueba de JS y programe la ejecución. Incluso puede hacer que AJAX le envíe los resultados para mantenerlo completamente automatizado.

Luego simplemente enjuague y repita sobre diferentes plataformas.


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


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"); }



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


Esta es una buena manera 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);


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

Usted podría simplemente usar temporizadores javascript. Pero normalmente obtengo resultados mucho más consistentes utilizando los métodos devTool de Chrome nativos (ahora también en Firefox y Safari) console.time console.time() & 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):

Chary canary recientemente agregó Perfil de nivel de línea en la pestaña de fuentes de herramientas de desarrollo que te permite ver exactamente cuánto tardó en ejecutarse cada línea.


La mayoría de los navegadores ahora están implementando la sincronización de alta resolución en performance.now() . Es superior a la new Date() para 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


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


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 procesaba bastante rápido, ninguna operación tomó mucho tiempo, solo se procesaba mucha información al mismo tiempo, por lo que el usuario se sentía lento.

''Arreglamos'' esto, no cambiando a un componente más rápido, u optimizando algún método, sino representando los datos primero, luego renderizando las cuadrículas con un 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, se mejoró el rendimiento percibido.

EDITAR: Esta respuesta tiene ahora 7 años. En estos días, el generador de perfiles de Chrome y otras herramientas están disponibles universalmente y son fáciles de usar, al igual que console.time() , console.profile() y performance.now() . Chrome también le ofrece una vista de la línea de tiempo que le puede mostrar qué está matando a su velocidad de fotogramas, 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 hacer que el código se ejecute para siempre, donde el usuario no lo notará, y el código que corre bastante rápido, y se quejarán de la respuesta. Código bastante rápido no siendo lo suficientemente rápido. O que su solicitud a su servidor API tomó 220ms. O algo más como eso. El punto es que si saca un generador de perfiles y busca trabajo para realizar, lo encontrará, pero puede que no sea el trabajo que sus usuarios necesitan.


Normalmente 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 javascript , pero el artículo solo muestra cómo probar cuánto tiempo se ejecuta el código 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".


Podrías usar console.profile en firebug


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



Siempre podemos medir el tiempo tomado por cualquier función por objeto de fecha simple .

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


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.


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

Vamos a examinar el rendimiento entre la function expression function constructor y el 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 anteriormente es crear una function expression function constructor y un function constructor realice la misma operación. El resultado es el siguiente:

Resultado FireFox Performance

Resultado de rendimiento de IE


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 toma en consideración todos los aspectos como la latencia, los tiempos de espera, etc.


Respuesta rápida

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

Respuesta larga

Si el lector no conoce la diferencia entre el índice 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 entender estos fundamentos ayudará también a las pruebas de rendimiento de JS. Algunos puntos destacados:

¿Qué es un punto de referencia?

Un punto de referencia es "un estándar de medición o evaluación" (Webster''s II Dictionary). Una referencia de computadora es generalmente un programa de computadora que realiza un conjunto de operaciones estrictamente definido (una carga de trabajo) y devuelve algún tipo de resultado, una métrica, que describe cómo se realizó la computadora probada. Las métricas de referencia de 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 la 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 que utilizan 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 limitaciones.

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. Lo ideal es que una prueba estandarizada sea portátil y que ya se haya ejecutado en las plataformas en las que está interesado. Sin embargo, antes de considerar los resultados, debe asegurarse de que comprende la correlación entre su aplicación / necesidades informáticas y cuáles son las el punto de referencia es la medición. ¿Son los puntos de referencia similares a los tipos de aplicaciones que ejecuta? ¿Las cargas de trabajo tienen características similares? Basándose en 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 está seleccionando un proveedor o un 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 por lo general 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 debe evitar.

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

Si algo está funcionando 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?