Rendimiento de TypeScript: Yendo más allá de la superficie

Rate this content
Bookmark

¿Alguna vez te encuentras preguntándote cómo identificar y abordar problemas de rendimiento en TypeScript para maximizar la efectividad de tu código? Si es así, únete a nosotros para una charla sobre el rendimiento de TypeScript y las técnicas que puedes utilizar para sacar el máximo provecho de tu código. Profundizaremos en varias formas de depurar el rendimiento, exploraremos cómo aprovechar el poder del compilador de TypeScript para detectar posibles problemas de rendimiento y utilizaremos las herramientas de perfilado disponibles para rastrear los cuellos de botella subyacentes.

Aleksandra Sikora
Aleksandra Sikora
34 min
21 Sep, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla de hoy proporciona una visión general del rendimiento de TypeScript y las herramientas para abordar los problemas de rendimiento. Cubre el proceso del compilador, incluyendo los pasos del analizador, vinculador, comprobador y transformadores. La charla enfatiza la importancia de mantener TypeScript actualizado para un mejor rendimiento. También discute estrategias para optimizar la compilación y depuración de TypeScript, analizando el rendimiento de la construcción utilizando archivos de traza, y mejorando el rendimiento simplificando los tipos y evitando la sobrecarga de los tipos de unión.

Available in English

1. Introducción al rendimiento de TypeScript

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
The Future of Performance Tooling
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
Optimizing HTML5 Games: 10 Years of Learnings
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Optimizing HTML5 Games: 10 Years of Learnings
Top Content
The open source PlayCanvas game engine is built specifically for the browser, incorporating 10 years of learnings about optimization. In this talk, you will discover the secret sauce that enables PlayCanvas to generate games with lightning fast load times and rock solid frame rates.
When Optimizations Backfire
JSNation 2023JSNation 2023
26 min
When Optimizations Backfire
Top Content
Ever loaded a font from the Google Fonts CDN? Or added the loading=lazy attribute onto an image? These optimizations are recommended all over the web – but, sometimes, they make your app not faster but slower.
In this talk, Ivan will show when some common performance optimizations backfire – and what we need to do to avoid that.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Miško Hevery
Miško Hevery
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Performance Debugging
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Maximize App Performance by Optimizing Web Fonts
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
Lazar Nikolov
Lazar Nikolov
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion
High-performance Next.js
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Michele Riva
Michele Riva
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.