1. Introducción al rendimiento de TypeScript
Hoy vamos a hablar sobre el rendimiento de TypeScript. Será una visión general de las herramientas existentes y cómo puedes utilizarlas para ayudarte a lidiar con diferentes problemas de rendimiento en TypeScript. Nos centraremos en la experiencia del desarrollador y en las herramientas. Un tiempo de compilación lento y un editor que se retrasa pueden ser bastante molestos y consumir mucho tiempo. Mantén tu TypeScript actualizado para un mejor rendimiento.
Hola a todos. Gracias a todos los que se unen. Hoy vamos a hablar sobre el TypeScript rendimiento. Así que unas palabras sobre mí antes de comenzar. Trabajo en código abierto en The Guild, principalmente en el GraphQL ecosistema, y también organizo un encuentro de TypeScript en Polonia. Puedes encontrarme en Twitter como AlexandraSays, o B-rows en GitHub. Y también siéntete libre de visitar mi sitio web personal, alexandra.codes. Así que esta charla tendrá tres partes principales, una introducción al tema del rendimiento, formas de depurar el rendimiento, y qué hacer para mejorarlo. Será como una visión general de las herramientas existentes y cómo puedes usar para ayudarte a lidiar con diferentes problemas de rendimiento en TypeScript. Así que empezaré con la introducción. En esta conferencia, probablemente todos ya sabemos qué es TypeScript y por qué lo estamos usando, así que iré directo al grano. ¿A qué me refiero con rendimiento hoy? Normalmente, cuando hablamos de rendimiento en informática, hablamos del rendimiento en tiempo de ejecución, como qué tan rápido son las cosas para nuestros usuarios. Pero hoy nos vamos a centrar en la experiencia del desarrollador y en nuestras herramientas. Y quería hablar de ello porque cuando estamos construyendo una característica o arreglando un bug en producción, nos gustaría ser como este piloto de Fórmula Uno. Nuestras herramientas deberían ponernos al día y no deberían ralentizarnos porque cuanto mejor sea nuestro proceso, más valor podemos entregar a los usuarios finales. Y creo que este es un tema importante porque como un tiempo de compilación lento y un editor que se retrasa pueden ser bastante molestos. Y lo que también es importante, puede ser bastante consumidor de tiempo. Así que nos gustaría evitar eso. Entonces, porque el equipo de TypeScript está haciendo mucho, realmente, realmente mucho tipo rendimiento mejoras, antes de que incluso vaya más allá con mi presentación, quiero que la primera conclusión de esta charla sea mantener tu TypeScript actualizado. Voy a mostrarte un ejemplo rápido. Así que hace unos meses, o tal vez incluso hace medio año, quería depurar problemas de rendimiento o ver si había alguno en la consola de Hasura. Esa era una base de código familiar para mí, porque solía trabajar allí. Así que pensé, vale, vamos a comprobarlo. Es una aplicación bastante grande. Y ejecuté el compilador de TypeScript y fueron casi 35 segundos. Creo que todos podemos estar de acuerdo en que eso es mucho. Y luego, antes de hacer cualquier depuración y mirar los tipos, actualicé TypeScript. En aquel entonces, la última versión era la 4.9.5. Y puedes ver
2. Entendiendo el Compilador de TypeScript y el Rendimiento
Y puedes comparar el tiempo de verificación, bajó de 31,5 segundos a menos de nueve. Eso fue enorme. Entonces, en primer lugar, gracias al equipo de TypeScript por todas las mejoras de rendimiento. Y en segundo lugar, recuerda mantener tu TypeScript actualizado. Podemos pensar lógicamente que si tenemos una base de código más grande, si tenemos más código, entonces TypeScript trabajará más lento considerando la cantidad de código que tenemos. Pero eso no siempre es el caso. Quiero mostrarte un ejemplo. Esto es más o menos de lo que vamos a hablar hoy, este tipo de problemas, y cómo detectarlos y tal vez qué hacer para evitarlos. Pero primero, antes de continuar, quería repasar cómo funciona un compilador.
es como tres veces más rápido. Esa es una diferencia realmente, realmente enorme. Y puedes comparar el tiempo de verificación, bajó de 31,5 segundos a menos de nueve. Eso fue enorme. Entonces, en primer lugar, gracias al equipo de
TypeScript por todas las mejoras de
performance. Y en segundo lugar, recuerda mantener tu
TypeScript actualizado. Puedes usar herramientas como dependabot u otras como renovate para hacerlo aún más fácil. Pero lo cierto es que no siempre es suficiente. Podemos pensar lógicamente que si tenemos una base de código más grande, si tenemos más código, entonces
TypeScript trabajará más lento considerando la cantidad de código que tenemos. Pero eso no siempre es el caso. Y quiero mostrarte un ejemplo. Así que lo que tengo aquí es una página simple que renderiza... Este es todo el código. Renderiza cuatro botones. Tengo un botón mediano, un botón pequeño, algún botón grande que se está creando a partir de... Este no es el archivo que quería mostrarte. Aquí está mi botón grande. Esto se crea usando la función de estilo de los componentes de estilo. También tengo un ancla de botón grande y también estoy usando la función de estilo. Esta es la única diferencia, esta es una ancla. Así que este código renderiza cuatro botones. Puedes ver aquí que el tiempo de compilación fue casi de 14 segundos, y creo que todos podemos estar de acuerdo en que eso no es ideal. Solo tenemos cuatro botones, imagina si tuviéramos ocho o algo así. Esto es más o menos de lo que vamos a hablar hoy, este tipo de problemas, y cómo detectarlos y tal vez qué hacer para evitarlos.
Pero primero, antes de continuar, quería repasar cómo funciona un compilador. Cuáles son los pasos en el compilador de TypeScript, porque creo que este conocimiento nos ayudará a entender mejor cómo afecta al performance, y tal vez también cómo nos permitirá identificar qué paso es responsable de nuestros problemas de performance, y a largo plazo, nos hará mejores programadores de TypeScript. Así que lo primero, la parte más importante, es el programa. Es como un objeto que tiene todo el contexto de compilación. Las dos cosas que se necesitan son obviamente algunos archivos de TypeScript y un ts.Config que describe cómo el compilador debe comportarse. Luego tenemos un paso de escaneo, que escanea el código fuente, carácter por carácter, y lo convierte en una lista de tokens. Si hay un token inválido, lanzará un error.
3. Entendiendo el Analizador de TypeScript y AST
Tenemos la palabra clave const, también reconoce espacios en blanco, tenemos identificadores, token de columna, y así sucesivamente. El siguiente paso es el analizador, que construye un árbol de sintaxis abstracta analizando los tokens. Este árbol aporta contexto al escáner y permite la identificación de declaraciones de variables. Herramientas como TypeScript AST Viewer y AST Explorer pueden ayudar a visualizar el código como un árbol de sintaxis abstracta.
Así que aquí tienes un ejemplo para esta simple línea de código. Tenemos la palabra clave const, también reconoce espacios en blanco, tenemos identificadores, token de columna, y así sucesivamente. Luego el siguiente paso es el analizador. Toma todos los tokens, toda esta lista y construye un árbol de sintaxis abstracta. Así que también puedes decir que aporta contexto al escáner. Por ejemplo, puedes ver el AST aquí. Así que cuando pasa por los tokens y dice que hay una palabra clave const y más adelante hay como un token de columna o un token igual, sabrá que será una declaración de variable por lo que puede construir este nodo de declaración de variable. Puedes usar herramientas como
TypeScript AST Viewer, o también está AST Explorer para visualizar tu código
4. Entendiendo el Paso del Vinculador
El siguiente paso es el Vinculador, que recopila información sobre el contexto, incluyendo metadatos para cada nodo del árbol, ámbitos y nodos padres. Esta información es utilizada por el verificador para determinar el tipo de un nodo. Es un paso importante y costoso en el proceso de compilación.
como el árbol de sintaxis abstracta. Ok, entonces el siguiente paso es el Vinculador y este es un paso muy importante. Recopila información sobre todo el contexto. Por lo tanto, es bastante costoso, es una única ejecución para todo el AST y recoge información que será utilizada en los pasos posteriores. Así que aquí hay un ejemplo. Una cosa que hace, almacena los metadatos para cada nodo del árbol. También mantiene un seguimiento de los ámbitos. Entonces, cuando estamos dentro de una función, ¿qué variables puedo usar, cuál es el ámbito de la función. Otra cosa es que establece nodos padres en cada nodo, de modo que más tarde, cuando el verificador tenga que ver cuál es el tipo de un nodo en particular, puede subir fácilmente
5. Entendiendo el Paso del Verificador
El paso del verificador en el compilador de TypeScript es responsable de verificar si los tipos son asignables entre sí y de realizar la inferencia de tipos. Rellena los vacíos en la información de tipo recorriendo el árbol de sintaxis abstracta y utilizando la información del padre para determinar el tipo de un nodo. Este paso es crucial para garantizar la seguridad de tipo en el código TypeScript.
el árbol. Lo explicaré en un segundo. Bien, así que ahora tenemos el paso del verificador. Y eso incluye la mayoría de los diagnósticos. Tiene dos responsabilidades principales. Una es que verifica si los tipos son asignables entre sí. Y la otra es que realiza la inferencia de tipos. Así que si hay algún vacío, no hay una tipificación explícita. Y si tenemos un nodo y aún no sabemos cuál es el tipo, es responsabilidad del verificador averiguarlo y llenar esos vacíos. Así que esto es por qué esta información sobre los padres es importante. Porque digamos que el verificador está en un nodo, y no hay información de tipo. Así que tal vez necesita subir por el árbol porque tal vez en algún lugar más arriba hubo una declaración de tipo explícita, o tal vez en algún lugar más arriba ya averiguó el tipo, por eso necesita hacerlo rápido. Y luego, una vez que descubre que, por ejemplo, tal vez hubo una declaración de tipo explícita para la función y estamos en algún lugar dentro de la función, puede recoger el tipo y luego volver a bajar por el árbol
6. Entendiendo el Paso de los Transformadores
Los transformadores eliminan la información sobre los tipos para el código JavaScript y dejan solo los tipos para los archivos de declaración. TypeScript Playground ofrece un plugin de escáner y transformadores de plugin AST para visualizar estos pasos.
para llenar el vacío. Bien, y luego tenemos los transformadores. Así que, en resumen, este paso toma el ASD y si queremos tener el código
Javascript, elimina toda la información sobre los tipos, y si queremos tener los archivos de creación, elimina todas las cosas relacionadas con
JavaScript y deja solo los tipos. Y finalmente obtenemos los archivos que solicitamos. Eso es si solicitamos alguno porque también puedes ejecutar TSD con la bandera de no emitir para hacer solo la parte de comprobación de tipos. Así que esto es más o menos lo que sucede en realidad, no es tan sencillo. Puede haber mucho de ida y vuelta entre los pasos. Pero solo quería darte una visión general de las partes importantes. También puedes probarlo en
TypeScript Playground. Hay un plugin de escáner también hay transformadores de plugin AST por lo que puedes visualizar algunos de esos pasos.
7. Optimizando la Compilación y Depuración de TypeScript
Con una base de código más grande y un código más complejo, la compilación de TypeScript puede ser lenta. Para mejorar el rendimiento, es importante depurar y entender qué necesita mejora. Ejecutar diagnósticos o diagnósticos extendidos puede proporcionar información básica sobre la base de código. La salida de diagnósticos incluye parseTime, bindTime, checkTime y emitTime, que pueden ayudar a identificar áreas para optimización. Además, herramientas como TSC Diagnostics Action y webTrimUp CLI pueden automatizar y visualizar el proceso de diagnósticos. Comprobar el número de archivos y líneas en la salida puede ayudar a determinar si la configuración de TypeScript es correcta. La bandera show config puede ser utilizada para ver la configuración final. Para comprobar los tipos, la bandera generate trace y un proyecto de demostración pueden ser útiles.
Bueno, vimos lo que está pasando y obviamente con una base de código más grande y un código más complejo eso puede ser lento. Todo eso como atravesar el AST y todo el tokenizado en el código eso puede llevar mucho tiempo. ¿Y cuál es la forma más fácil de ser más rápido? Y puedes pensar sobre esta pregunta en términos de no sólo el compilador de TypeScript sino en general si tienes una larga lista de tareas pendientes y quieres terminar el día y disfrutar de tu tarde, ¿qué puedes hacer para terminar más rápido? Bueno, la respuesta podría ser hacer menos cosas. Y bueno, la cosa es con el compilador de TypeScript que no podemos eliminar algunos de esos pasos pero podemos hacer que haga menos trabajo y vamos a ver cómo más tarde. Así que la primera parte es la depuración porque sin saber qué deberíamos mejorar, realmente no podemos mejorar nada. Así que la pregunta es que mi construcción tarda una eternidad, mi IDE está retrasado, ¿y ahora qué puedo hacer? Así que lo primero que suelo hacer es ejecutar diagnósticos o diagnósticos extendidos y esto nos dará alguna información básica sobre lo que está pasando en la base de código. Así que esta es una salida de los diagnósticos plug. Puedes ver cómo se mapea a diferentes pasos del compilador, tenemos este parseTime, bindTime, checkTime, y emitTime. Y si quieres algo que lo haga más fácil, como algo que lo automatiza sin que tengas que ejecutarlo en tu base de código de vez en cuando, creé esta Acción de GitHub muy, muy minimalista. Se llama TSC Diagnostics Action. Y básicamente, para cada PR, te da esta comparación de diagnósticos. Puedes configurarlo para tener diferentes salidas. Pero volviendo a la salida del paquete de diagnósticos. Así que, la primera pregunta que puedes hacerte es, ¿estos números, el número de archivos, líneas de TypeScript, JavaScript, JSON, y así sucesivamente, ¿corresponden aproximadamente al número de archivos en tu proyecto? Porque si no, entonces tal vez TypeScript está recogiendo demasiados archivos y tal vez eso significa que tu configuración de prueba no es correcta. Así que, una cosa que puedes hacer es que puedes ejecutar una lista de archivos, como este TSC lista de archivos, con el plug de lista de archivos, y ver cuáles son exactamente todos los archivos que TypeScript está recogiendo. Mientras que la salida de este plug no es muy amigable para el usuario y no muy fácil de leer, puedes usar esta herramienta webTrimUp CLI para visualizarla. Abrirá este HTML en tu navegador con todo lo que es importante visualizado, así que puedes ver qué está tomando, qué archivos son significativamente grandes, y así sucesivamente. Te ayudará a detectar que tal vez estás compilando algo que realmente no quieres. Bueno, otra cosa es el alto tiempo de programa o tiempo de escritura. Así que eso también puede indicar que la configuración no es correcta. Y quería mostrarte otra bandera. Hay show config. Es especialmente útil cuando tienes como, usas extends en tu config, y extiendes una config después de otra. Así que a veces es bastante difícil saber cuál es realmente la configuración final. Y esa bandera de show config puede ayudarte con eso porque esto imprimirá como la actual configuración que TypeScript está usando para tu proyecto. Bueno, y ahora la parte más importante, y creo que la parte más interesante, un hi check type. Así que para eso, normalmente estoy usando la bandera generate trace, y voy a mostrarte una demostración rápida. Tengo un proyecto aquí. Simplemente escogí un proyecto aleatorio de la página del Explorador de GitHub, básicamente. Sólo quería jugar con
8. Analizando el Rendimiento de la Construcción de TypeScript
Ejecuto el comando generate trace utilizando yarn tsc guion guion generate trace. El archivo trace JSON se puede cargar en el navegador, lo que permite analizar el rendimiento. Al examinar el archivo de traza, puedes identificar archivos problemáticos y localizar la verificación de tipos lenta. En este ejemplo, el archivo TRPC TS y la función underscore apt-get parecen estar causando la desaceleración. TypeScript sugiere agregar una anotación de tipo explícita para resolver el problema. Esto es valioso cuando se trabaja con una base de código grande o cuando se intenta identificar cambios que pueden haber causado una desaceleración.
diferentes proyectos. Y ejecuto el comando generate trace. Básicamente, para hacer esto, ejecutas este
yarn tsc guion guion generate trace, y también tienes que proporcionar un directorio de salida. Yo ya hice esto antes. Para no perder tiempo en eso, lo tengo aquí. Genera un archivo trace JSON y un archivo types JSON. Ahora, ¿qué puedo hacer con este trace JSON, porque también probablemente puedes ver que no es muy fácil de leer. Lo estoy cargando en el navegador. Así que lo tengo aquí. Así que puedes abrir, como si estás usando Chrome, puedes abrir como about tracing, o puedes ir a como puedes abrir las herramientas de desarrollador e ir a
performance y cargarlo allí. Hay un botón, haces clic en él, y luego eliges el archivo de traza que acabas de generar. Y vas a ver algo como esto. Así que ahora cuando abro este archivo, puedo ver que tal vez hay algo que está yendo mal. Así que en este ejemplo, una cosa que noto es que alrededor de aquí, parece que hay mucho sucediendo. Y si hago clic en este check source file, también puedo aprender cuál es el archivo que está siendo problemático. Y eso ya me da alguna información. Sé dónde buscar mis problemas. Y luego si bajo con este check expressions, puedes ver que el metadato aquí es ligeramente diferente. También tengo la ruta, pero tengo la posición y el final. Este check source file sólo tenía la ruta, así que básicamente, puedes identificar dónde la verificación de tipo es lenta. Así que puedo ir incluso más abajo. Veo ahora que estoy en el archivo TRPC TS. Ahora estoy en underscore apt-get, y supongo que este es algo en lo que puedo profundizar. Así que si abro este archivo, lo copiaré, volveré al proyecto. Así que si lo abro, pegué el error por si no funciona durante esta presentación, pero ya puedo ver que
TypeScript me dice que el tipo de entrada de este nodo excede la longitud máxima que el compilador serializará. Se necesita una anotación de tipo explícita. Entonces, está bien, sé dónde está el problema, qué está causando que mi tiempo de construcción de
TypeScript sea más lento. Y sé que este es el lugar que probablemente quiero refactorizar. Esto es bastante útil, porque imagina que estás trabajando en una base de código grande, y, o tal vez te fuiste de vacaciones y alguien, como otras personas, estaban trabajando en la base de código. Vuelves y te das cuenta de que el tiempo de construcción es mucho más largo. ¿Y cómo procedes? ¿Dónde lo buscas? ¿Repasas todos los PRs, todos los comentarios que la gente añadió para ver qué fue posiblemente cambiado que causó el problema? Bueno, esa es una forma.
9. Analizando la Comparación de Tipos con Generate Trace
El uso del comando generate trace permite una identificación más rápida de archivos problemáticos y una lenta verificación de tipos. Al copiar la ID y navegar a la base de código, puedes localizar el tipo que se está comparando. Los tipos de origen y destino, junto con información adicional como argumentos de tipo, se pueden encontrar en el archivo JSON del tipo.
Pero el uso de este generate trace te llevará allí mucho, mucho más rápido. Y también quería mostrarte otra cosa. Aquí hay un segundo lugar que parece que lleva bastante más tiempo, este archivo en particular. Es este handle children event types test, PS. Así que aquí tenemos otras cajas. Tenemos este check the part note con este tipo de metadatos. Tenemos check variable decoration, check expression. También tenemos algo como structure tied related to. Y aquí tenemos source id y target id. Así que esos son como las ideas de los tipos que se están comparando.
¿Y ahora qué hacer con eso? Bueno, no hay información para rastrear en sí mismo. Así que realmente no sabes cuál es el tipo. Pero si podemos copiar esta id y dirigirnos a la base de código. Y si vamos a este archivo JSON de tipos que no miramos antes. Déjame hacer más espacio. Hay algo como ir a la línea en VS Code. Y puedes ir a esta línea en particular. Tenemos esta id. Y ahora sabemos cuál es el tipo que se está comparando. Sabemos que la primera declaración está en el paquete just mock-extended. Y también sabemos cuál es el inicio, cuál es el final. Y a veces también hay información adicional. Así que sabemos que este es nuestro origen, que se está comparando. Y el objetivo, volveré a ir a la línea, y el objetivo es Prisma Client. También sabemos cuáles son los argumentos de tipo. Este es un tipo genérico. Tenemos esta primera declaración, apunta a los modules de nodo. Y a veces también tenemos información de visualización. Así que no estoy seguro si puedo mostrar. Por ejemplo, aquí tenemos esta visualización, te muestra exactamente el código aquí en este espacio.
10. Trabajando con Trace JSON y Types JSON
Y ahora si vamos a este archivo que estamos depurando, podemos ver que hay algo como Prisma Mock. Así es más o menos como trabajas con el trace JSON y el archivo types JSON que se generó. También puedes usar una herramienta llamada analyze-trace para obtener información sobre los puntos críticos en tu código. También estamos trabajando en una extensión llamada TS-PERP para facilitar la experiencia.
Y ahora si vamos a este archivo que estamos depurando, podemos ver que hay algo como Prisma Mock. Y aquí es donde se está utilizando este just mock extended. Así que esto es más o menos cómo trabajas con el trace JSON y el archivo types JSON que se generó.
Vale. Ahora volvamos a las diapositivas. Esta. Vale. También puedes usar una herramienta llamada analyze-trace y se te proporciona el directorio de salida que te gusta donde se generaron el types JSON y trace JSON y te dará información sobre algunos puntos críticos en tu código de manera predeterminada.
Ahora también hay algo en lo que Daniel y yo, que también está hablando en esta masterclass, estamos pensando y trabajando lentamente. Queríamos hacer esta experiencia un poco más fácil. Así que estamos pensando en algo llamado, este es un nombre provisional, TS-PERP y esto va a ser, por ahora, una extensión de VS Code. Hice una grabación por si algo sale mal porque esto es un trabajo en progreso. Así que básicamente te voy a mostrar cómo esta extensión genera el rastreo para ti y ejecutas un comando para mostrar el rastreo. Así que te ahorra un poco de ida y vuelta entre el navegador y tu proyecto y también tenemos algunas otras ideas, así que mantente atento.
11. Mejorando el Rendimiento de TypeScript
Hay varias formas de encontrar problemas con el rendimiento de TypeScript. En primer lugar, si no funciona como se espera, revisa tus configuraciones. El equipo de TypeScript ha creado una wiki de rendimiento con consejos útiles, como nombrar tipos complejos y extraerlos a alias de tipo separados. Además, simplificar los tipos puede mejorar el rendimiento, aunque puede requerir refactorización de código.
Bien, ahora las diapositivas y la parte de mejora. Entonces, hay varias formas en las que básicamente puedes tener problemas. Así que la primera es que no funciona de la manera que se supone que debe funcionar. Eso probablemente significa que tienes que revisar tu configuración, tal vez tu exclude, include o pys no están configurados correctamente. Puedes hacer referencia a esta página tsconfig, como aprenderás allí sobre todas las opciones de configuración y cómo configurarlo para que realmente haga lo que quieres. Y ahora digamos que tenemos eso cubierto. Funciona de la manera que se supone que debe funcionar, pero aún así está haciendo demasiado trabajo. Así que ahora tenemos algunas mejoras que podemos hacer como el equipo de TypeScript creó esta wiki de performance con muchos, muchos tips útiles. Te voy a mostrar solo algunos con algunos ejemplos.
Entonces, aquí tengo dos ejemplos. Creo que solo tengo tiempo para mostrarte uno. Este es solo un cambio de la biblioteca de validation en runtime de Zote. Entonces, básicamente lo que pasó aquí, puedes ver que este Zote, lo haré un poco más grande. Bien, puedes ver que el error formateado de Zote era bastante complejo. Como que había mucho pasando. Tenemos tipos condicionales y podemos suponer que, ya sabes, CacheGrid probablemente tiene mucho trabajo que hacer allí. Entonces, básicamente lo que hizo el autor de DPR fue extraer la parte compleja, la que tiene tipos condicionales, a un alias de tipo separado y usarlo para ZotFormattedError. Y creo que en esta descripción, podemos ver cuál fue la mejora. Entonces podemos ver que el tiempo de verificación pasó de 31 a 20 segundos. Eso, diría que eso es mucho. ¿Y por qué sucedió eso? Es porque Typescript ahora puede almacenar en caché este alias de tipo por lo que no tiene que recalcular eso cada vez que se usa ZotFormattedError. Y eso causó esta mejora. Bien, entonces este es el primer consejo, nombra tipos complejos, extráelos a alias de tipo separados. Otra cosa es hacer tus tipos más simples. Te mostré esta demostración con startComponents, ¿verdad? Entonces, la razón por la que está tomando tanto tiempo es porque estoy usando muchas funciones de nivel superior complejas de startComponents, este Time, este Memo. Entonces, esto es en realidad de React y startComponents, pero este es de startComponents. Entonces, Typescript tiene que hacer muchas inferencias para averiguar las props. Entonces, en ese caso, no hay una solución fácil, no hay una solución de una línea para los tipos. Como algo que necesitaba hacer aquí era realmente refactorizar mi código. Y lo tengo aquí.
12. Optimizando TypeScript con Tipado Explícito
Creé nuevos componentes sin usar este tipo, proporcioné las props, las tipé explícitamente. Ejecutar diagnósticos extendidos mostró una mejora significativa en el rendimiento. La simplicidad puede llevar a un mejor rendimiento. En otro ejemplo, descubrí que proporcionar explícitamente un parámetro genérico en un generador de código GraphQL ayudó a mejorar la inferencia de TypeScript. Depurar un archivo lento reveló que inferir el primer parámetro causaba la desaceleración. Proporcionar el parámetro genérico explícitamente eliminó los puntos críticos en la base de código.
Básicamente, creé nuevos componentes sin usar este tipo, proporcioné las props, las tipé explícitamente. Así que lo tengo. Lo tengo aquí. Tengo esos tipos y aquí mi botón básico se ve así.
Así que ahora si ejecuto los diagnósticos extendidos para ver la diferencia, creo que será pnp. Bien, sí. Sí. Puedes ver que esto es mucho más rápido. Son solo dos segundos. Bueno, ese fue otro ejemplo. Y la conclusión de aquí es que a veces lo más simple significa mejor. Y lo más simple también puede significar más performance.
Y otro ejemplo bastante interesante, algo que encontré en uno de los proyectos en los que estaba trabajando, un generador de código GraphQL. A veces puedes ayudar a TypeScript. Pero hay, agregué esto, si realmente lo necesitas. Como, puedes confiar en la inferencia de TypeScript la mayor parte del tiempo. Pero solo, quería compartir este ejemplo en particular porque lo encontré interesante.
Entonces, comencé mostrándote el rastro. Sí, aquí vamos. Así que este es el rastro generativo de este proyecto. Puedes ver que este archivo, este Babel.ts está tomando mucho tiempo. Entonces, fui, como, lo depuré. Resultó ser alrededor de esta función declarer y particularmente sobre inferir este primer parámetro, las opciones aquí. Y lo que hice, proporcioné este parámetro genérico explícitamente. Así que tipé estas opciones de preajuste del cliente Babel como lo que realmente usamos. Y eso ayudó bastante. Te mostraré el rastro después del cambio, para que puedas ver que ya no hay puntos críticos en la base de código. Y eso sucedió porque ahora puedes ver que este, el segundo parámetro genérico, tiene un tipo predeterminado. Hay este objeto Babel.plugin. Pero porque el primero no lo tiene, TypeScript tenía, como, siempre necesitaba ejecutar la inferencia para esto.
13. Mejorando el Rendimiento de TypeScript: Consejos Prácticos
El rendimiento de TypeScript se puede mejorar siendo razonable y sin exagerar. Evite declarar un gran número de elementos en un tipo de unión, ya que puede ralentizar significativamente la compilación. Si se han realizado mejoras y correcciones de configuración pero el rendimiento sigue siendo lento, se puede utilizar la bandera incremental para almacenar en caché la información de compilación. Al abrir un problema, asegúrese de estar utilizando la última versión de TypeScript e incluya la salida de diagnósticos extendidos y el rastro del uso generado. Depurar problemas de rendimiento con la salida de rastro generada puede ayudar a identificar áreas de mejora. Para obtener más información, visite alexana.code y consulte la entrada del congreso de TypeScript.
Entonces, porque proporcioné el primero, básicamente hice algo aquí, entonces TypeScript puede usar este por defecto para el segundo parámetro. Ese fue mi conjunto de otro ejemplo, y la diferencia fue que el tiempo de verificación pasó de un segundo y medio a 0.88. Y creo que el último ejemplo que quería mostrarles es ser razonable. Entonces, TypeScript tiene muchas características realmente increíbles. Una de ellas son, cerraré esto lentamente, las cadenas de texto de plantillas. Entonces puedes hacer mucho de eso. Pero a veces tal vez quieras preguntarte cuánto quieres hacer, porque este es un ejemplo de uno de los problemas reportados en TypeScript. Entonces básicamente tenemos este tipo, cadena de fecha completa, y como el año, ese mes, y el día todo se declara con plantillas. Y puedes ver, si paso el cursor sobre él, que hay más de 74 mil elementos en esta unión. Y eso es bastante. Entonces, aunque tengo un código realmente corto aquí, como son 30 líneas de código, 29 si cuento correctamente, esto toma, ¿qué es eso?, casi dos minutos para compilar. Eso es mucho. Y el tiempo de verificación es, sí, es ligeramente menor que el tiempo total. Entonces es casi como, también casi como dos minutos. Entonces, la conclusión aquí es también ser razonable. No exageres y no patines en Rake.
Entonces, digamos que hicimos algunas mejoras y también arreglamos la configuración si había algún problema. Entonces funciona como se supone que debe hacerlo. Está haciendo el mínimo trabajo requerido, pero aún es lento. Ahora lo que puedes hacer es que puedes usar la bandera incremental. Puedes configurarlo en las opciones del compilador. Eso permitirá que TypeScript almacene en caché alguna información sobre la compilación. Entonces, cada vez que recompiles el proyecto, TypeScript calculará cuál es el menor esfuerzo posible para hacerlo. Entonces no compilará archivos que fueron cambiados, por ejemplo. Y si todavía está mal, puedes abrir nuevos problemas. Entonces, algunos consejos para hacerlo. En primer lugar, asegúrate de que estás utilizando el último TypeScript. Tal vez tus problemas ya están resueltos. También tienes que incluir la salida de diagnósticos extendidos, el rastro del uso generado y una reproducción mínima o tal vez un enlace al repositorio, si eso es posible. Entonces, para resumir, vimos algunas herramientas y vimos cómo depurar los problemas de rendimiento con la salida de rastro generada. Espero que te sea útil. Y realmente, realmente espero que no tengas que lidiar con ningún problema de rendimiento. Pero si lo haces, aquí tienes una visión general de los pasos que puedes tomar para mejorar la base de código. Bueno, eso es todo por mi parte. Todo eso lo puedes encontrar en mi sitio web si vas a alexana.code y a mi página de charlas. Y si encuentras la entrada del congreso de TypeScript, encontrarás las notas de esta presentación. Gracias a todos.
React Summit 2023
