12 publicaciones etiquetados con "benchmarks"

En V8, siempre estamos buscando mejorar el rendimiento de JavaScript. Como parte de este esfuerzo, recientemente volvimos a analizar el conjunto de pruebas de JetStream2 para eliminar caídas de rendimiento. Esta publicación detalla una optimización específica que realizamos y que generó una mejora significativa de 2.5x en la prueba de referencia async-fs, contribuyendo a un aumento notable en la puntuación general. La optimización se inspiró en el benchmark, pero este tipo de patrones también aparecen en código del mundo real.

Bienvenido al emocionante mundo de V8, donde la velocidad no es solo una característica, sino un estilo de vida. Al despedirnos de 2023, es hora de celebrar los impresionantes logros que V8 ha alcanzado este año.

A través de innovadoras optimizaciones de rendimiento, V8 continúa ampliando los límites de lo que es posible en el paisaje en constante evolución de la Web. Hemos introducido un nuevo compilador de nivel intermedio y hemos implementado varias mejoras en la infraestructura del compilador de nivel superior, el tiempo de ejecución y el recolector de basura, lo que ha resultado en importantes ganancias de velocidad en general.

Durante sus tres meses de prácticas en el equipo de V8, Hai Dang trabajó en mejorar el rendimiento de [...array], [...string], [...set], [...map.keys()] y [...map.values()] (cuando los elementos extendidos están al inicio del literal de array). Incluso hizo que Array.from(iterable) fuese mucho más rápido. Este artículo explica algunos de los detalles de sus cambios, que están incluidos en V8 a partir de la versión 7.2.

El procesamiento asíncrono en JavaScript tradicionalmente tenía la reputación de no ser particularmente rápido. Para empeorar las cosas, depurar aplicaciones JavaScript en vivo — en particular servidores Node.js — no es una tarea fácil, especialmente cuando se trata de programación asíncrona. Afortunadamente, los tiempos están cambiando. Este artículo explora cómo optimizamos las funciones asíncronas y las promesas en V8 (y hasta cierto punto en otros motores de JavaScript), y describe cómo mejoramos la experiencia de depuración para el código asíncrono.

DataViews son una de las dos maneras posibles de realizar accesos a memoria de bajo nivel en JavaScript, siendo la otra los TypedArrays. Hasta ahora, los DataView estaban mucho menos optimizados que los TypedArray en V8, lo que resultaba en un menor rendimiento en tareas como cargas de trabajo intensivas gráficamente o al decodificar/codificar datos binarios. Las razones de esto han sido principalmente elecciones históricas, como el hecho de que asm.js eligió TypedArray en lugar de DataView, incentivando a los motores a centrarse en el rendimiento de los TypedArray.

Este mes marca el décimo aniversario del lanzamiento no solo de Google Chrome, sino también del proyecto V8. Esta publicación ofrece un resumen de los hitos principales del proyecto V8 en los últimos 10 años, así como los años anteriores, cuando el proyecto aún era secreto.

Desde el lanzamiento inicial de Speedometer 1.0 en 2014, los equipos de Blink y V8 han utilizado este benchmark como un proxy para el uso real de frameworks populares de JavaScript y hemos logrado aceleraciones considerablemente en este benchmark. Verificamos de manera independiente que estas mejoras se traducen en beneficios reales para los usuarios al medir contra sitios web reales y observar que las mejoras en los tiempos de carga de páginas de sitios web populares también mejoraron la puntuación de Speedometer.

El rendimiento de JavaScript siempre ha sido importante para el equipo de V8, y en esta publicación nos gustaría hablar sobre un nuevo Benchmark de Herramientas Web de JavaScript que hemos estado utilizando recientemente para identificar y corregir algunos cuellos de botella de rendimiento en V8. Probablemente ya estés al tanto del fuerte compromiso de V8 con Node.js, y este benchmark amplía ese compromiso al ejecutar específicamente pruebas de rendimiento basadas en herramientas comunes para desarrolladores construidas sobre Node.js. Las herramientas en el Benchmark de Herramientas Web son las mismas que los desarrolladores y diseñadores utilizan hoy en día para crear sitios web modernos y aplicaciones basadas en la nube. Continuando con nuestros esfuerzos en curso para centrarnos en el rendimiento en el mundo real en lugar de benchmarks artificiales, creamos el benchmark usando código real que los desarrolladores ejecutan a diario.

Los proxies han sido una parte integral de JavaScript desde ES2015. Permiten interceptar operaciones fundamentales en objetos y personalizar su comportamiento. Los proxies forman una parte esencial de proyectos como jsdom y la biblioteca Comlink RPC. Recientemente, hemos puesto mucho esfuerzo en mejorar el rendimiento de los proxies en V8. Este artículo aporta algo de luz sobre los patrones generales de mejora de rendimiento en V8 y en proxies en particular.

La historia de los benchmarks de JavaScript es una historia de evolución constante. A medida que la web se expandió de simples documentos a aplicaciones dinámicas del lado del cliente, se crearon nuevos benchmarks de JavaScript para medir cargas de trabajo que se volvieron importantes para nuevos casos de uso. Este cambio constante ha dado a los benchmarks individuales una vida útil limitada. A medida que los navegadores web y las implementaciones de máquinas virtuales (VM) comienzan a sobreoptimizar casos de prueba específicos, los propios benchmarks dejan de ser proxies efectivos para sus casos de uso originales. Uno de los primeros benchmarks de JavaScript, SunSpider, proporcionó incentivos tempranos para implementar compiladores de optimización rápidos. Sin embargo, a medida que los ingenieros de VM descubrieron las limitaciones de los microbenchmarks y encontraron nuevas formas de optimizar en torno a las limitaciones de SunSpider, la comunidad de navegadores retiró SunSpider como un benchmark recomendado.