V8 utiliza almacenamiento en caché de código para guardar el código generado de scripts usados frecuentemente. A partir de Chrome 66, almacenamos más código en caché al generar el caché después de la ejecución a nivel superior. Esto genera una reducción del 20–40% en el tiempo de análisis y compilación durante la carga inicial.
TL;DR: A partir de Chrome 66, V8 compila el código fuente de JavaScript en un hilo en segundo plano, reduciendo el tiempo dedicado a la compilación en el hilo principal entre un 5% y un 20% en sitios web típicos.
Desde la versión 41, Chrome ha admitido la análisis de archivos fuente de JavaScript en un hilo en segundo plano mediante la API StreamedSource de V8. Esto permite que V8 comience a analizar el código fuente de JavaScript tan pronto como Chrome haya descargado el primer fragmento del archivo de la red y continúe analizando en paralelo mientras Chrome transmite el archivo por la red. Esto puede proporcionar mejoras considerables en el tiempo de carga, ya que V8 puede estar casi terminado de analizar el JavaScript para cuando el archivo haya terminado de descargarse.
Depurar fugas de memoria en Chrome 66 se ha vuelto mucho más fácil. Las DevTools de Chrome ahora pueden trazar y capturar objetos DOM en C++ y mostrar todos los objetos DOM accesibles desde JavaScript junto con sus referencias. Esta funcionalidad es uno de los beneficios del nuevo mecanismo de trazado en C++ del recolector de basura de V8.
TL;DR: La deserialización perezosa se habilitó recientemente de manera predeterminada en V8 v6.4, reduciendo el consumo de memoria de V8 en más de 500 KB por pestaña del navegador en promedio. ¡Sigue leyendo para saber más!
Pero primero, demos un paso atrás y echemos un vistazo a cómo V8 utiliza snapshots de heap para acelerar la creación de nuevos Isolates (que corresponden aproximadamente a una pestaña de navegador en Chrome). Mi colega Yang Guo dio una buena introducción sobre este tema en su artículo sobre snapshots personalizados de inicio:
Los objetos de JavaScript en V8 se asignan en un montón administrado por el recolector de basura de V8. En publicaciones anteriores del blog ya hemos hablado sobre cómo reducimos los tiempos de pausa de la recolección de basura (más de una vez) y el consumo de memoria. En esta publicación del blog presentamos el Scavenger paralelo, una de las características más recientes de Orinoco, el recolector de basura principalmente concurrente y paralelo de V8, y discutimos las decisiones de diseño y enfoques alternativos que implementamos en el camino.
En esta publicación queremos presentar el CodeStubAssembler (CSA), un componente en V8 que ha sido una herramienta muy útil para lograr algunos grandes mejoras de rendimiento en las últimas versiones de V8. El CSA también mejoró significativamente la capacidad del equipo de V8 para optimizar rápidamente las funciones de JavaScript a un nivel bajo con un alto grado de confiabilidad, lo que mejoró la velocidad de desarrollo del equipo.
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.
Hace aproximadamente tres meses, me uní al equipo de V8 (Google Munich) como pasante y desde entonces he estado trabajando en el Desoptimizador de la máquina virtual, algo completamente nuevo para mí que resultó ser un proyecto interesante y desafiante. La primera parte de mi pasantía se enfocó en mejorar la seguridad de la máquina virtual. La segunda parte se centró en mejoras de rendimiento, específicamente en la eliminación de una estructura de datos utilizada para la desvinculación de funciones previamente desoptimizadas, que representaba un cuello de botella de rendimiento durante la recolección de basura. Esta publicación describe esta segunda parte de mi pasantía. Explicaré cómo V8 solía desvincular funciones desoptimizadas, cómo cambiamos esto y qué mejoras de rendimiento se obtuvieron.
Nota: Si prefieres ver una presentación en lugar de leer artículos, ¡disfruta del video a continuación!
Los objetos en JavaScript pueden tener propiedades arbitrarias asociadas a ellos. Los nombres de las propiedades de los objetos pueden contener cualquier carácter. Uno de los casos interesantes que un motor de JavaScript puede elegir optimizar son las propiedades cuyos nombres son puramente numéricos, más específicamente índices de arrays.
En esta publicación de blog queremos explicar cómo V8 maneja las propiedades de JavaScript internamente. Desde el punto de vista de JavaScript, solo se necesitan unas pocas distinciones para las propiedades. Los objetos JavaScript se comportan principalmente como diccionarios, con claves de cadena y objetos arbitrarios como valores. Sin embargo, la especificación trata las propiedades con índices enteros y otras propiedades de manera diferente durante la iteración. Fuera de eso, las diferentes propiedades se comportan mayormente de la misma manera, independientemente de si tienen índices enteros o no.