Rust and JavaScript Integration

Oh, estoy muy honrado de estar aquí. Y espero que hayan tenido un gran almuerzo. Y hoy mi tema es sobre los socios de REST sin benchmark. Pero no se preocupen. Es la nación JS. No hablaremos mucho sobre REST. En su lugar, hablaremos sobre el uso de REST en JavaScript.

Así que un poco sobre mí. He sido desarrollador front-end durante unos diez años. Soy desarrollador web, pero también soy desarrollador para desarrolladores. Así que disfruto tanto TypeScript como REST. Durante el día, escribo TypeScript, y por la noche, escribo REST. Soy el autor de ASTGRAP, que es una herramienta de búsqueda de código. Si estás interesado, puedes verlo en Twitter o en GitHub.

REST se está volviendo cada vez más popular en JavaScript. No es sin razón. Así que REST no solo es rápido, sino que también es predeciblemente rápido, a diferencia de JavaScript, que tiene un compilador just-in-time que mostrará un rendimiento impredecible durante diferentes cargas de trabajo. REST es predeciblemente rápido. Y también tiene un gran ecosistema, como Cargo, que es el NPM, o el renderizador de tareas para REST. También tiene Crate.io, que es NPM. Y también es muy fácil integrar REST en JavaScript usando Naughty.js.

Sin embargo, REST no es una bala de plata. Tiene un alto costo de aprendizaje. Y si lo introduces en tu proyecto, deberías esperar menos colaboradores. Y lo más importante, es muy difícil diseñar un plugin para REST porque es un lenguaje nativo. No puedes inyectar lógica arbitraria en tu código nativo. Así que necesitamos un plugin de JavaScript. El plugin de JavaScript es más personalizable y más fácil de usar para nuestros usuarios finales. Y una parte crítica de un plugin JS es que debe entender y modificar nuestro código. Así que eso introduce nuestro tema de hoy.

Así que nuestro plugin de JavaScript debe convertir nuestro código textual en un formato AST comprensible. Antes de comenzar nuestro benchmark, debemos entender una cosa. Que llamar a la función REST desde JavaScript es costoso. Involucra alguna conversión extra y pasos para realmente obtener algunos datos de REST. Tal como esta imagen. Se llama llamada a función extranjera. Si no estás familiarizado con este término, puedes pensar en ello como viajar al extranjero.

Así que podemos ver aquí, oh, un cangrejo de Rust quiere entrar al mundo de JavaScript. Pero es muy difícil para él. Así que podemos pensar en la función extranjera, como la función REST, como el destino al que queremos ir. Y los argumentos que pasamos a esa función son el equipaje. El valor de retorno es el souvenir. Y la convención de llamada para la función extranjera es como la visa y el pasaporte. Y de manera similar, cuanto más equipaje y souvenirs tengas, más dinero y tiempo necesitas para revisarlos y empacarlos. Eso es también lo mismo para la función extranjera. Cuanto más grande sea la función que llames, más tiempo necesitas gastar.

Muy bien. Hablemos sobre nuestro diseño de benchmark. Primero, necesitamos elegir analizadores. Hoy tenemos tres categorías de analizadores. Así que el primero son los analizadores basados en TreeSetter. TreeSetter es una biblioteca en C que puede analizar nuestro código de manera incremental. Y ASDGrep es una biblioteca construida sobre eso. También tenemos analizadores REST nativos. SWC y OXC son dos opciones populares. Finalmente, tendremos analizadores basados en JavaScript. Se eligen como la línea base de nuestro benchmark. Y tengo un descargo de responsabilidad. El presentador, yo, es el autor de ASDGrep, así que veremos algunos resultados centrados en eso. Pero seré justo.

Y tenemos dos factores para nuestro benchmark. Así que el primero es el tamaño del archivo. Así que necesitaremos evaluar el rendimiento de nuestros parsers en diferentes códigos. Tenemos cuatro niveles aquí. Analizaremos un solo archivo, un archivo pequeño, un archivo mediano y un archivo muy grande. También necesitamos considerar el nivel de concurrencia. Porque como nos dijo la película de Spider-Man, con más núcleos viene más rendimiento.

Así que simularemos nuestra carga de trabajo analizando cinco archivos al mismo tiempo. Haremos eso tanto de manera sincrónica como asincrónica. Así que podemos ver aquí, en la forma sincrónica, usaremos un bucle for para analizar archivos uno por uno secuencialmente. Y en la versión asincrónica, analizaremos estos archivos concurrentemente usando promise.all para analizarlos al mismo tiempo.

Muy bien. Veamos el resultado del rendimiento. Así que primero, el rendimiento se calcula como operación por segundo. Y el parser más rápido tiene un puntaje del 100%. Y los otros parsers tienen un porcentaje del puntaje del parser más rápido. Así que aquí, cuanto mayor sea el porcentaje, mejor será el rendimiento. Podemos ver aquí, una línea cian, que representa a TypeScript, se sitúa en la parte inferior de todas las otras líneas. Así que eso básicamente significa que TypeScript supera consistentemente a otros competidores. Y también podemos ver esta línea azul, línea roja, línea verde y la línea naranja. Así que todos estos son parsers nativos. Así que todas estas líneas generalmente subieron. Así que eso implica que los parsers nativos muestran un mejor rendimiento para archivos más grandes. Y finalmente, Babel ha demostrado un rendimiento algo inestable porque la línea sube y baja.

Veamos la versión asincrónica. Así que el rendimiento se calcula de manera similar a antes. Y hemos visto un cruce muy interesante. Así que ASTGrab, la línea azul, ganó la competencia al analizar archivos medianos a grandes. Y el TypeScript, la línea cian, y la línea roja, TreeSitter, experimentaron una disminución en el rendimiento al analizar archivos más grandes. Y el SWC y el OXC, la línea verde y la línea naranja, se mantienen mayormente planas, sugiriendo que tienen un rendimiento consistente.

Para entender nuestro resultado del benchmark, primero necesitamos entender cómo se desglosa el tiempo de análisis. Así que podemos descomponer el tiempo de análisis en tres categorías. La primera es la interfaz de función extranjera. Así que es un costo fijo para invocar funciones a través de diferentes lenguajes. Y también tenemos el tiempo de análisis, que es el tiempo real que procesamos los archivos. Así que generalmente crece cuando analizamos archivos más grandes. Y finalmente, tenemos el tiempo de serialización y deserialización. Eso es porque no podemos consumir directamente la estructura de datos de Rust en JavaScript. Así que necesitamos convertir los datos de Rust en un formato compatible con JS. El costo de serialización puede ser un costo fijo o variable. Depende de la implementación real. Lo veremos más adelante.

Así que primero veamos la sobrecarga de FFI. Tenemos una tabla aquí. La tabla aquí demuestra todos los puntajes de rendimiento que vimos antes. Así que primero veamos la línea uno. Así que la línea uno representa la línea base de la sobrecarga de FFI. Eso es porque el costo del tiempo de análisis y el costo de serialización son mínimos. Podemos ver aquí que TypeScript es el rey aquí. Y el costo de FFI es menos significativo a medida que el archivo crece. Porque el costo de FFI es en gran medida independiente del tamaño del archivo. Podemos ver aquí que el rendimiento de ASD graphs crece al 78% desde el 72% cuando está analizando archivos más grandes. Así que sugiere alrededor de un 6% de sobrecarga de FFI para invocar una función de Rust. Y también FFI es más pronunciado en el análisis asincrónico. Podemos ver aquí que el rendimiento de ASD graphs cae al 60% en la versión asincrónica. Esto es principalmente porque en la versión asincrónica necesitamos configurar más código como el bucle de eventos llamando y callbacks para JavaScript. Y SWC, curiosamente, tiene una implementación única. Así que el rendimiento no cambia en la versión sincrónica y asincrónica.

Veamos también la sobrecarga de serialización. Puede que te preguntes por qué SWC y OXC, estos dos parsers rápidos, no logramos replicar su impresionante rendimiento.

Eso es porque estamos usando JSON.parse aquí. Hablamos antes, JavaScript no puede consumir directamente la estructura de datos de Rust. Tenemos que serializar el AST en Rust a JavaScript. Así que aquí usamos JSON.parse en el flujo de JSON. Y toda la estructura de datos AST se empaqueta en el flujo de JSON y se envía a JavaScript. Si JavaScript va a analizar este flujo de JSON y serializarlo en un objeto de JavaScript, este paso es muy lento. Y es por eso que nuestro benchmark no logra replicar este rendimiento impresionante.

Una cosa interesante es que el tree setter y el AST graph evitan el costo de serialización. Así que en lugar de empaquetar todo el árbol AST en el flujo de JSON, están devolviendo un nuevo objeto de árbol. Podemos ver aquí que tenemos un objeto especial llamado SD root, que es un envoltorio de objeto alrededor de la estructura de datos de Rust. Así que no necesitamos pagar el costo al principio. Sin embargo, para acceder a los nodos del árbol, todavía necesitamos invocar el método de Rust desde JavaScript. Aquí podemos ver en JavaScript, el nodo SD, la clase de datos que representa el nodo AST tendrá texto, padre e hijos, lo que significa, está bien, si quiero leer el texto AST de un nodo, tengo que llamar al método de texto. Pero llamar a este método nos costará algo de tiempo. Así que en realidad estamos distribuyendo el costo de serialización sobre la lectura.

Y finalmente, revisemos el análisis paralelo. Así que los parsers de JavaScript son más lentos cuando analizan archivos concurrentemente. Porque JavaScript es un lenguaje de un solo hilo, y el análisis es una tarea ligada a la CPU. Así que los archivos deben ser analizados uno por uno en el hilo principal, uno tras otro. Por otro lado, casi todos los parsers nativos pueden tener soporte paralelo, excepto TreeSetter. Es más debido a la implementación de TreeSetter.

Y tenemos un resumen de rendimiento aquí. Así que en esta tabla, tenemos celdas coloreadas que representan diferentes características de rendimiento para nuestros parsers. Así que la celda amarilla, constante, denota que es un tiempo constante que no cambia con el tamaño de la entrada. Y proporcional, la celda roja, indica que el tiempo dedicado a esta tarea crece con el tamaño de la entrada. Eso básicamente significa que, si estoy analizando un archivo más grande, más tiempo necesito dedicar.

Y finalmente, tenemos una celda verde. No disponible significa que, está bien, no necesitamos dedicar tiempo a esa tarea. Lo más importante, los parsers basados en JavaScript como Babel y TypeScript no tienen tiempo de FFL y tiempo de serialización. Finalmente, tenemos el análisis paralelo. Así que para el análisis paralelo, casi todos los parsers nativos tienen soporte paralelo, mientras que los parsers de JavaScript no.

Así que hagamos un resumen de nuestro rendimiento. Así que los parsers basados en JavaScript se ejecutan completamente en el motor de JavaScript, por lo que no tienen ninguna sobrecarga de función extranjera o sobrecarga de serialización. Solo tienen tiempo de análisis, pero ese tiempo de análisis crecerá con el tamaño de la entrada. Por otro lado, los parsers nativos o los parsers basados en Rust están influenciados por un costo fijo de FFI, un costo de análisis variable y un costo de serialización. La sobrecarga de serialización variará dependiendo de la implementación diferente. Para AST graph y tree shader, es un costo de serialización fijo porque solo serializan un objeto de árbol.

Por otro lado, SLUC y OXC tendrán un costo de serialización variable proporcional al tamaño de la entrada porque serializan todo el árbol. Y finalmente, los parsers nativos pueden ser paralelos, mientras que los parsers de JavaScript no pueden.

Para resumir nuestro benchmark de rendimiento de hoy, tengo varios trucos para ti. Entonces, ¿cómo podemos hacer que nuestro parser de Rust sea más rápido? Lo primero es evitar la serialización al principio. Así que podemos devolver un objeto de Rust envuelto a Node.js. Sin embargo, no es una bala de plata. Puede llevar a una lectura de datos AST más lenta en JavaScript. Sin embargo, cuando solo necesitamos algunos nodos específicos en el árbol AST, no necesitamos serializar todo el árbol. Así que si tienes algunos escenarios específicos, como, está bien, solo necesitas saber la importación o exportación de archivos JavaScript, puedes usar este truco. Así que no necesitas serializar otras cosas en tu JavaScript.

Otra cosa es que deberíamos explotar o aprovechar múltiples núcleos de CPU. Así que el código nativo puede usar tareas asíncronas para el análisis de múltiples núcleos. Así que la tarea asíncrona es una abstracción en la API de Node.js. Esa tarea es independiente del hilo principal. Podemos ver el gráfico aquí. Todas las tareas asíncronas están programadas en el hilo WV. Y para el hilo WV, son independientes del hilo principal. Así que no bloqueará la ejecución de JavaScript. Y también, para Node.js, los pools de hilos WV tienen un tamaño predeterminado de 4. Así que también podemos usar el argumento de línea de comandos de Node.js para cambiar ese número. Y expandir el tamaño del pool también puede mejorar el rendimiento.

Así que eso es todo de mi charla de hoy. Y gracias JavaScript Nation por tenerme aquí. Y si sientes que esta charla fue útil, por favor dale una estrella o sígueme. Gracias. Así que, nuestra primera pregunta, es de Anónimo. Y es para el SWC slash OXC. ¿Qué porcentaje del tiempo total de ejecución se gasta en Stair Day en promedio? Es difícil hablar sobre el porcentaje. Porque el tiempo varía en las diferentes partes. Porque el tamaño de archivo diferente tomará diferente...

Necesitarás dedicar diferentes tiempos para diferentes tamaños de archivos. Pero en mi experiencia, alrededor del 50%, si estamos analizando un archivo grande, el 50% del tiempo se dedica a la serialización. Pero, no, solo mi experiencia y mi experimento, el tiempo puede variar.

Sí. Bien. Sí, gracias. Y no tenemos ninguna otra... Más preguntas de la audiencia en este momento. Pero siéntete libre de hacer cualquier pregunta que tengas. Pero solo me estaba preguntando... ¿Hay alguna aplicación de algunas de estas cosas para el desarrollador promedio de JavaScript? ¿O es principalmente para personas que están, supongo, tratando de conectar... Personas que están tratando de trabajar en estos compiladores de Rust?

Entonces, básicamente, si estás trabajando en la construcción de herramientas, necesitarás conectarte con estos parsers de Rust. Así que la mayoría de nuestros cuellos de botella de rendimiento se encuentran en el análisis de código. Por ejemplo, si estás usando Webpack o Rollup, entonces tienes que analizar tu código en un formato AST. Y luego necesitas ese formato para hacer alguna agrupación de código. También hay algo de tree shaking. Así que si tienes estos requisitos específicos, tocarás los compiladores de Rust. Y puede que no necesites escribir código Rust tú mismo. Pero sin embargo, necesitarás conocer la API expuesta por estos compiladores.

Bien. Y tenemos otra pregunta de Nicholas. ¿Podría un modelo basado en eventos con una sincronización de árbol funcionar mejor para optimizar FFI? Necesito... ¿Te gustaría repetir esa pregunta? ¿Podría un modelo basado en eventos con una sincronización de árbol funcionar mejor para optimizar FFI? Así que puede que no entienda la pregunta al 100% correctamente. Pero entiendo que si el compilador puede emitir algún evento durante el análisis, entonces nosotros podemos construir algunos hooks alrededor de eso. Y eso puede evitar algunos costos de serialización. Esa es mi comprensión. Así que, según mi comprensión, esto debería ayudar. Pero dicho esto, tienes un soporte limitado para operaciones arbitrarias en tu árbol AST. Así que eso es básicamente porque, significa que tienes que diseñar un evento o un conjunto completo de hooks que tu usuario final pueda consumir en el análisis del compilador. Si olvidas algo o los requisitos del usuario cambian mucho, entonces ese hook del compilador puede no funcionar más. Así que diría que sí, mejorará el rendimiento. Sin embargo, puede que no sea lo suficientemente flexible como para simplemente exponer el objeto AST en sí mismo.

Bien. Bien. Bueno, gracias, Harrington. Esas son todas las preguntas que tenemos para ti. Solo para que sepas, si tienes más preguntas, puedes ir a la sala de preguntas y respuestas del ponente. Y es la sala de cristal allá. Y Harrington estará disponible para preguntas adicionales si piensas en algunas después de esto. Y asegúrate de calificar esta charla en Slido. Y vamos a tener un breve descanso. Así que si quieres cambiar de sala para la próxima charla, y puedes consultar todas las charlas en el sitio web o la aplicación. Así que eso es todo. Gracias.