El Proyecto OXC y el Efecto de la Ingeniería de Rendimiento

Hola a todos. En esta charla, hablaré sobre el compilador de oxidación de JavaScript (OXC) y el efecto de la ingeniería de rendimiento en este proyecto. Para comenzar, mi nombre es Baotian. Durante la última década, mi trabajo ha sido como ingeniero de configuración frontend. He configurado muchas herramientas de JavaScript como Grunt, Go, Webpack, y muchas más. Como parte de mi interés en experimentar con nuevos lenguajes de programación, comencé a trabajar de cerca con herramientas de JavaScript escritas en Rust. Estos proyectos incluyen Roldown, RSpec, BIOME, SWC y RBRs. Al mismo tiempo, inicié y me convertí en el líder del proyecto OXC. Entonces, ¿qué es el proyecto OXC? Es una colección de herramientas de JavaScript escritas en Rust. Algunas partes son independientes y otras partes son compatibles con otros proyectos. Las herramientas completas son las primeras tres. El analizador, que actualmente es tres veces más rápido que SWC, el linter, que es de 50 a 100 veces más rápido que ESLint, dependiendo del número de núcleos de CPU que utilices, y una herramienta modular de resolución llamada el resolutor, que es 28 veces más rápido que el de Webpack.

resultado mejorado. Las próximas tres cosas en las que estamos trabajando actualmente son: un formateador, que será bastante compatible, un transformador o transpilador que será compatible con bisel y, por último, el modificador BigBoss. Y finalmente, OXC también admite las estrellas en ascenso, los paquetes Roldown y RSpec. Es bastante difícil mostrar por qué OXC es lo próximo grande, así que dejaré que estas personas hablen por mí. Ivan Yu quedó asombrado por la velocidad de OXLint, que es un linter para OXC. Lo ejecutó en el repositorio de Vue y tardó 50 milisegundos. Joe Savanna, líder del equipo de React en Meta, mostró interés en el proyecto y lo encontró agradable. Eric Simons, CEO de StackBlitz, también reconoce que podría ser lo próximo grande. Y Miles, el creador del repositorio Moon, quedó asombrado nuevamente por OXLint.

Por último, tenemos a Jason Miller, Shopify DX y creador de Preact, quien dijo lo siguiente. OXLint ha sido una gran victoria para nosotros en Shopify. Nuestra configuración anterior de linting tardaba 75 minutos en ejecutarse, así que lo estábamos descubriendo en 50 trabajadores pasados en CI. En comparación, OXLint tarda alrededor de 10 segundos en analizar la misma base de código en un solo trabajador y la salida es más fácil de interpretar. Incluso encontramos algunos errores que estaban ocultos o se omitieron en nuestra configuración anterior cuando hicimos la migración. Y después de unos meses, hablé de nuevo con Jason y dijo que probablemente ahorraron millones de dólares en infraestructura después de cambiar.

Permítanme mostrar rápidamente una demostración del linter. Aquí tenemos OXLint ejecutándose en el repositorio de VS Code. En mi Mac Pro, completó 4.8k archivos en 850 milisegundos con los 90 utilizando todos los núcleos. Sí, el linter terminó todo el repositorio de VS Code en menos de un segundo. Ahora veamos los diagnósticos, donde para cada regla intentamos señalar el mismo problema exacto. A veces ni siquiera necesitas leer el mensaje de error para entender qué está mal en el code. La primera regla, no expresión binaria constante, es mi regla favorita, que ha estado en la versión 8 de ESLint durante más de un año. Esta regla podría haber evitado tantos errores en el último año si se hubiera activado de forma predeterminada en ESLint cuando se introdujo por primera vez. Pero desafortunadamente, activar nuevas reglas rompe la compatibilidad, por lo que debe introducirse en una versión importante y solo se activó de forma predeterminada en la versión 9, que se lanzó en abril. En mi opinión, una de las principales tareas del linter es detectar errores ocultos, por lo que estas reglas que revelan errores deberían activarse de forma predeterminada lo antes posible para ayudar a las personas a enviar un mejor code. Los usuarios de OXLint han estado disfrutando de esta regla desde el principio. Y como por ejemplo, para esta regla, es bastante obvio, pero no es obvio que el operador de conocimiento tiene una precedencia más baja. Entonces, para corregir el code, en realidad necesitas un paréntesis aquí. Y para estas reglas, si solo miras la línea roja, probablemente entenderás qué está mal en el code y lo corregirás. Lo que realmente me emociona de OXLint hoy en día es que podemos realizar linting entre archivos. Esto significa que podemos implementar reglas del complemento de ESLint import, que son notoriamente lentas si habilitas ciertas reglas, como la regla sin ciclo.

En la parte izquierda de la pantalla. Sin embargo, en OXLint, el linting entre archivos se realiza en paralelo y se comparten los AST. Por lo tanto, la única sobrecarga que encontramos es esperar a que los archivos dependientes terminen de pasar. Una vez más, en el repositorio de VS Code, ejecutar completamente la regla sin ciclo en menos de un segundo, lo que probablemente llevaría mucho tiempo con el complemento de ESLint import. Y creo que el diagnóstico es un poco mejor, muestra cuál es el ciclo. Si vincular el repositorio de VS Code en menos de un segundo no es impresionante, también lo probé en el gran repositorio interno, completó 122,000 archivos en 3.4 segundos. Lo que esto implica es que si colocas todos los repositorios de tu empresa o tus propios proyectos uno al lado del otro y luego ejecutas OXLint en el árbol principal, deberías poder analizar todo tu código de una vez en un par de segundos. Esto es genial porque con cada actualización de OXLint, probablemente encontrarás algunos errores más para toda tu empresa o tus proyectos en unos segundos, lo que ahorra mucha carga de mantenimiento y dinero en infraestructura. Entonces, ¿cómo comenzó todo? Bueno, mi enfoque en el rendimiento comenzó hace dos años durante el confinamiento. En realidad, me quedé con una computadora portátil súper lenta, un Intel i5 con solo 8 gigabytes de RAM. Todo era tan lento. No tenía nada más que hacer, pero esta computadora portátil puso mi perspectiva del tiempo en cámara lenta. En ese momento, descubrí el proyecto Bion, que en ese momento se llamaba Roam. Introduje todo el concepto de cadena de herramientas integradas de herramientas frontend, pero me enfrenté a dos problemas. Uno es el problema de la computadora lenta y el otro es el síndrome del impostor. No sabía lo que estaba haciendo, así que terminé aprendiendo desde cero. Desde aprender qué es un AST o qué es un impostor, ni siquiera era bueno en Rust en ese momento. Seguí aprendiendo y persistí agregando más código. Y ahora, muchos meses después, cuando salí del confinamiento, descubrí esto. De alguna manera creé el analizador de JavaScript más rápido escrito en Rust y aprendí con una velocidad inimaginable. El rendimiento juega un papel tan importante en el proyecto. Así que eventualmente llegué a este principio después de inspirarme en algunos miembros de la comunidad. Todos los problemas de rendimiento se consideran errores en este proyecto. Por lo tanto, el rendimiento no solo significa el tiempo de ejecución del programa, sino también la velocidad de compilación y el tiempo de integración continua. Todo lo que se sienta lento debe solucionarse como máxima prioridad. Permítanme demostrar estos conceptos con el repositorio OXE. Esta es la página de acciones de GitHub que muestra el tiempo de ejecución de todos los trabajos. Ejecuta pruebas en Windows, Ubuntu, macOS y WebAssembly, y luego verifica la salud del código base. Todos los trabajos se completan en aproximadamente tres minutos, lo que creo que es más rápido que la mayoría de los proyectos Rust más grandes y algunos de los proyectos JavaScript más grandes también. Así que creo que para que un proyecto se mantenga bien, debe proporcionar a los colaboradores un ciclo de retroalimentación muy rápido cuando no están familiarizados con el proyecto.

Y tengo una historia que contar. Como sabrán, también trabajo en el proyecto ISPAC. El tiempo de CI era de aproximadamente una hora cuando me uní, y me llevó un mes reducirlo a 20 minutos. No tenía más trucos bajo la manga. Intenté solucionar cada problema de código que existía, pero eventualmente me rendí porque no había nada más que arreglar o era demasiado difícil de solucionar. Así que lo último que hice fue convencer a mis gerentes de invertir dinero en el problema y reducir el tiempo de CI a cinco minutos. Los tiempos lentos de CI cuestan tiempo humano, y hacerlo más rápido puede costar mucho dinero.

También tenemos una configuración de referencia llamada benchmarking continuo utilizando Cosby como herramienta y plataforma. Lo que hace Cosby es registrar métricas como los ciclos de CPU utilizando Valgrind, y luego calcula un número de velocidad y lo almacena en una base de datos para confirmar los errores. Esto hace que el benchmarking sea confiable, eliminando el hardware de la computadora de la ecuación. Esta captura de pantalla muestra una de las mejoras de rendimiento más sorprendentes en la historia del proyecto OXC, que hizo que nuestro analizador fuera dos veces más rápido que FWC y que se ejecutaran todos nuestros benchmarks de prueba, casos de prueba, que hay alrededor de más de una docena de casos de prueba, y todo se hace en cinco minutos. Sí, cuando envías código al repositorio OXC, obtendrás este resultado de referencia en cinco minutos.

El rendimiento es en realidad un concepto muy vago cuando trabajamos en él. A menudo se descuida y es lo último en considerarse para un proyecto. Es difícil convencer a las personas de trabajar en el rendimiento como una prioridad hasta que se vuelva realmente lento, principalmente debido a la famosa falacia. La optimización prematura del código fuera de contexto es la raíz de todos los males. Pero todo esto cambió cuando comencé a ver el curso abierto del MIT sobre el rendimiento en términos de sistemas de software. En su primera conferencia, afirmó lo siguiente. El rendimiento es la concurrencia de la computación. A menudo, puedes comprar propiedades necesarias con el rendimiento. Es realmente difícil entender qué son las propiedades necesarias. Bueno, en realidad hay cosas como corrección, testabilidad, mantenibilidad, confiabilidad, usabilidad, todo tipo de cosas que vienen con la creación de un software. El rendimiento es una de ellas.

Para demostrar este concepto, aquí tenemos una hoja de conformidad que prueba todas nuestras herramientas contra test262, Babel y las hojas de prueba de Hydro. Básicamente verifica el comportamiento de nuestras herramientas en comparación con nuestros predecesores para asegurarnos de que cumplamos con el mismo comportamiento. Aquí en esta captura de pantalla, completamos la ejecución de más de 50k casos de prueba en solo dos minutos y medio. Creo que el tiempo de ejecución de las pruebas se convierte en un cuello de botella para una base lógica cuando se llega a tantos casos de prueba. Pero en NeoXe, como todo es rápido, también se completan las pruebas más rápido. Si no te has dado cuenta por los números en la captura de pantalla, actualmente pasa el 99% de los casos de prueba. Esto significa que el analizador está listo para producción y se puede utilizar. Cuando hablo de comprar propiedades con el rendimiento, creo que también podemos comprar innovación con el rendimiento.

Este es nuestro último tema, el rendimiento como camino hacia la innovación. Cuando trabajaba en la infraestructura de JavaScript, siempre me preguntaba por qué necesitábamos compilar JavaScript y publicarlo en SDNs. Disfrutamos de las últimas características de JavaScript, pero necesitan ser transpiladas a una versión más antigua y luego enviadas al usuario, lo que resulta en un código inflado. Y luego, sitios web lentos. Es donde sacrificamos rendimiento por el último grupo de usuarios.

Hemos estado haciendo esto desde el principio porque el rendimiento es realmente el elefante en la habitación. Debido a que la transpilación es lenta, la modificación es lenta, empujar a CDN y servir archivos también. Todo es un poco lento. Cuando Jared Sumner creó BAN, su objetivo de proyecto era crear un empaquetador, no un tiempo de ejecución como el que estamos viendo ahora. Se dio cuenta de forma independiente de que una vez que se alcanza el rendimiento máximo, podemos simplemente empaquetar bajo demanda con una capa de almacenamiento en caché. De esta manera, los usuarios que utilizan navegadores más nuevos obtendrán archivos más pequeños, lo que lleva a sitios web más rápidos.

Y esta es una captura de pantalla de las pruebas de rendimiento para nuestros minificadores de JavaScript actuales. Tenemos SWC, ESBuild y dos minificadores escritos en Go, el tercero y el quinto. Y uno escrito en Rust, el primero SWC. Y luego, cuando estás escribiendo JavaScript, el segundo, AgilifyJS, entra en el número seis. Lo interesante es que la actual era de herramientas escritas en Rust y Go puede minificar un megabyte de archivo. Pero las herramientas de la era pasada no pueden. Para muchos códigos base más grandes y aplicaciones web más grandes, la cantidad de código que enviamos al usuario es aún mayor. A medida que nuestros códigos base crecen cada vez más, especialmente para aplicaciones web grandes, algunas de las herramientas existentes se vuelven realmente lentas, simplemente se quedan sin memoria. Lo que es realmente interesante, sin embargo, es el compilador de cierre de Google en la lista. En realidad tiene un modo avanzado, que probablemente pueda superar a otras herramientas en tamaño de compresión. Pero desafortunadamente, solo funciona en la infraestructura de Google y nadie más puede usarlo porque es realmente, realmente lento. Realiza una gran cantidad de pases ASD en Java. Sin embargo, no podemos culparlos. El compilador de cierre de Google fue creado tan temprano y Java era el único lenguaje admitido internamente.

Entonces, si OXC tiene la oportunidad, todo nuestro trabajo actual nos llevará a crear nuestro propio minificador, que apuntará a tener el mejor tamaño de compresión similar al compilador de cierre de Google con un rendimiento más pequeño que SWC y ESP. Así que OXC fue mi proyecto independiente durante los últimos dos años, pero ya no lo será. El proyecto ahora tiene la misión de admitir completamente a Rolldown founder y buscar soluciones mejores y más nuevas para la infraestructura de JavaScript con Yzero, la empresa.

Y si tienes alguna pregunta, no dudes en visitar nuestro sitio web o contactarme en nuestro Discord o en mi Twitter. Gracias por escuchar.