¿Cuánta RAM está usando tu UseMemo? ¡Vamos a perfilarlo!

El uso de memoria es una parte comúnmente pasada por alto en las aplicaciones web modernas, con frameworks como React intercambiándolo por performance y facilidad de desarrollo. La razón por la que hacemos esto es que normalmente las aplicaciones web son lo suficientemente simples. Y la memoria en los clientes es abundante. ¿Pero es esto siempre el caso? ¿Y qué hacemos cuando no lo es?

Hola, soy Giulio Zauza, soy ingeniero de software. Y quería traerte algunas lecciones que aprendí de la manera difícil mientras optimizaba una aplicación React compleja. De hecho, estoy trabajando en una aplicación web compleja llamada Flux. Es una herramienta CAD electrónica basada en navegador que permite un diseño rápido y colaborativo de circuitos eléctricos y PCB design. Bajo su capó, es una gran aplicación de tipo script que usa WebGL para renderizar documentos complejos, y está construida usando React, 3.js y Reactive Fiber.

Estamos trabajando duro en performance ya que queríamos que la aplicación fuera rápida y receptiva pero también escalable. Necesitamos poder soportar documentos gigantes con miles de componentes, cada uno hecho de docenas de formas complejas. Originalmente, pensamos que el tiempo congelado durante las interacciones y FPS eran las cosas a optimizar, pero pronto nos dimos cuenta de que eso era en realidad solo una parte del panorama. Al hacer ese tipo de optimization, a veces intercambias el uso de memoria por performance, lo cual es algo que en nuestro caso se volvió en nuestra contra. De hecho, construimos un sistema de renderizado usando mucha memorización siempre que fue posible, y usamos cachés para prevenir re-renderizados, y usamos muchas precomputaciones. Esto inicialmente comenzó a hacer que la performance fuera mejor, pero en cierto punto, en realidad empeoró las cosas. El uso de memoria era muy, muy alto al abrir proyectos más grandes y superaba fácilmente la marca del gigabyte. Hicimos esas optimizaciones porque seguimos lo que todavía se considera una mejor práctica para performance con React, que es usar la memorización tanto como sea posible. De hecho, incluso hay un artículo famoso que aboga por usar la memorización de React para cada valor de símbolo conocido. Lo que encontramos, sin embargo, es que usar esta estrategia puede volverse perjudicial ya que afectará su uso de memoria de formas incluso inesperadas.

Bueno, pero podrías preguntar, ¿por qué nos importa el uso de memoria? Especialmente ahora que los clientes tienen más RAM que nunca. Bueno, hay tres formas en las que el uso de memoria afecta negativamente a su aplicación. La primera es que los navegadores limitan mucho su uso de memoria. Chrome para escritorio, por ejemplo, tiene un límite de memoria duro alrededor de cuatro gigabytes por pestaña. En el momento en que superas ese límite, el navegador simplemente matará tu pestaña sin ninguna forma de recuperarte de ello. Y este límite se vuelve aún menor en dispositivos móviles como Safari, iOS, por ejemplo. La segunda razón es que cuanto más uso de memoria pesa en el recolector de basura. Incluso si estás tratando de optimizar solo por velocidad, probablemente verás muchas entradas en tus perfiles de tiempo relacionados con actividades de recolección de basura como mi GC mayor y menor. Eso está sucediendo cuando se realizan demasiadas asignaciones de memoria en un corto período de tiempo y el navegador se ve obligado a pausar tu aplicación para ocuparse de ellas. Y la tercera razón es que usar demasiada memoria empeora la user experience. Muchos usuarios están usando su dispositivo para varias cosas a la vez. Y esto significa que si tu aplicación web está reteniendo gigabytes enteros de memoria, harás que la user experience de todo lo demás que se ejecuta en su cliente sea significativamente peor.

Y debido a esas razones, diría que probablemente, independientemente del tipo de aplicación que estés construyendo, siempre es una buena idea vigilar el consumo de memoria de tu aplicación y optimizarlo cuando sea necesario, especialmente ahora que Chrome está empezando a informar a los usuarios sobre el consumo de memoria de las pestañas individuales cuando pasas el cursor sobre el título de la pestaña. Imagina ejecutar una simple aplicación de lista de tareas y ver que ocupa medio gigabyte. Diría que esa no es una buena impresión.

Entonces, supongamos que te encuentras en una de esas situaciones y quieres mejorar las cosas para tu aplicación. ¿Cómo lo haces? Bueno, el enfoque que suelo seguir se basa en tres puntos. El primero es que necesitas identificar qué es lo que está ocupando tanta memoria en tu aplicación. Y luego, una vez que has encontrado lo que está ocupando demasiada RAM, puedes usar algunas estrategias para optimizarlo. Y por último, quieres intentar evitar que esas cosas vuelvan a suceder en el futuro. Y puedes usar pruebas de memoria automatizadas en tu pipeline de CI para esto. En esta masterclass, nos centraremos solo en el primer punto, ya que los otros dos puntos también son muy grandes y dependen de la implementación.

Cuando se trata de analizar el uso de memoria, creo que es útil introducir algunos términos y hacer algunas distinciones primero. La primera es sobre el uso de memoria transitoria versus estática. Llamamos uso de memoria estática al conjunto de asignaciones de memoria que permanecen algo estables durante la ejecución de la aplicación, y es la que esperarías encontrar al tomar una instantánea del heap cuando tu aplicación está en estado estable. El uso de memoria transitoria, en cambio, es cuando tu aplicación asigna mucha memoria de una vez y la libera poco después, creando un pico en el uso de memoria. Esto podría ser muy difícil de detectar solo con una instantánea del heap, y un pico muy grande podría hacer que tu aplicación se bloquee.

Otra distinción importante es conteo versus tamaño. Puedes tener unidades individuales de asignación que ocupan mucha memoria. Pero también puedes tener muchas asignaciones más pequeñas, que por sí solas son lo suficientemente pequeñas. Pero juntas llenan tu RAM. En el segundo caso, puede ser más difícil encontrarlas y optimizarlas. Luego tenemos dos términos que aparecen a menudo en los perfiles de memoria, que son memoria superficial y retenida. Como JavaScript se basa en el uso de estructuras de data anidadas y punteros, hay una distinción entre el tamaño de un objeto en sí versus el tamaño al que ese objeto apunta. Por ejemplo, podemos tener un array de 10 elementos, cada uno siendo una cadena diferente con un millón de caracteres cada uno. Debido a su tamaño, las cadenas ocuparán en total alrededor de 10 megabytes, mientras que el array solo ocupará unas pocas docenas de bytes. Dado que el array está conteniendo y reteniendo esas cadenas, diremos que el tamaño retenido de ese array sería de 10 megabytes de todos modos, ya que es la razón por la que la cadena se ha mantenido en memoria de todos modos.

Lo último que creo que es importante introducir son los diferentes tipos de asignación dentro de la Máquina Visual de JavaScript. Chrome, por ejemplo, hace la distinción entre objetos, arrays, cadenas, arrays tipados, y también es importante notar cómo incluso tu código JS ocupa espacio en memoria. Y al navegar por los resultados de una instantánea de memoria, puedes aprender algunas cosas muy interesantes, como el hecho de que la función JS por sí sola puede ocupar espacio como si fueran objetos, ya que necesitan llevar un registro de sus cierres. Por lo tanto, es mejor evitar crear funciones en bucles por esta razón.

Bien, ahora que hemos establecido algunos términos, veamos las herramientas que están disponibles para analizar el uso de memoria.

El punto de partida es, por supuesto, el Analizador de Memoria de Chrome, que tiene tres opciones de análisis disponibles. Es posible que descubras que la instantánea del heap y el muestreo de asignaciones son las opciones más útiles. Pero para dos propósitos diferentes. La instantánea del heap toma una imagen completa del uso actual de la memoria en un punto dado en el tiempo, proporcionándote un desglose de los tipos de objetos en memoria y por qué se están reteniendo. Usando una instantánea del heap, puedes observar diferentes tipos de objetos, su uso de memoria superficial, y su uso de memoria retenida como dijimos antes.

Con cualquier instantánea, sin embargo, te falta información sobre lo que está cambiando con el tiempo y no puedes observar los picos transitorios de uso de memoria. Si estás interesado en los picos de uso de memoria, puedes utilizar el método de muestreo de asignaciones. Puedes iniciarlo y detenerlo más tarde y después de ejecutarlo durante algún tiempo, te proporciona un gráfico, describiendo cuánto se asignó durante el tiempo y por qué funciones. Esta es una herramienta realmente poderosa para depurar picos de uso de memoria, pero es menos adecuada para analizar la huella de memoria total de tu aplicación en un estado estable. Y solo usando estas dos herramientas, puedes hacer optimizaciones de uso de memoria realmente poderosas.

Por ejemplo, puedo mostrarte cómo las usamos para optimizar la actualización y el trabajo. Después de tomar una instantánea de memoria de la aplicación Flux en un estado estable, podemos hacer clic en las columnas de tamaño superficial y retenido para ordenar los tipos de asignación por uso de memoria y con suerte encontrar los mayores infractores y eliminarlos. Podemos verificar ambos, tanto retenido como superficial, para que podamos encontrar tanto asignaciones individuales grandes como ubicaciones más pequeñas que están reteniendo una gran cantidad de memoria. Y mientras mirábamos esa lista, había algo que destacaba de inmediato.

Tenemos muchos objetos de mapa, alrededor de 10,000, la mayoría de ellos bastante pequeños, pero aparte del primero, que estaba ocupando alrededor de 84 megabytes de RAM. Y eso inmediatamente pareció una gran alerta roja ya que no sabía que teníamos un mapa tan grande para algo en la aplicación. Y en la parte inferior de la interfaz de usuario del perfilador, podemos ver por qué y quién estaba reteniendo ese gran objeto de mapa, que resultó ser una variable global que estábamos utilizando para suscribirnos a eventos. De hecho, cada vez que en nuestra aplicación ocurre una suscripción, estamos utilizando un hook useState para generar y almacenar un UID de cadena, que luego se utilizaba para eliminar la suscripción en CleanApp. Resultó ser extremadamente ineficiente para el consumo de memoria, ya que necesitaba instanciar el hook useState, almacenar la cadena, y también mantener el cierre alrededor de esa función lambda. Y al eliminar esa llamada al hook useState y reemplazar el mapa que mantenía las cadenas solo por una estructura de conjunto data, pudimos reducir la huella de memoria de las suscripciones, lo que ahorró incluso un 50% de RAM en algunos casos. Y este es un ejemplo de una estructura de datos data obviamente ineficiente en memoria, que fue fácil de encontrar y optimizar.

Desafortunadamente, sin embargo, eso no siempre es el caso. De hecho, fue una de las pocas cosas fáciles que pudimos optimizar en nuestra aplicación. Si miras este perfil, puedes ver cómo la mayoría restante de la huella de memoria está dominada por objetos. Y desafortunadamente, ya no tenemos un solo objeto para optimizar, sino más bien dos millones de instancias de objetos más pequeños que se mantienen en memoria. El analizador de memoria de Chrome no facilita la comprensión ya que no agrupa los objetos por tipo. Y no hay forma de que puedas desplazarte manualmente por todos ellos y averiguar qué está pasando. Afortunadamente, sin embargo, el analizador de memoria de Chrome puede exportar tu instantánea del heap a un archivo JSON. Así que hay esperanza para nosotros para realizar algún análisis estadístico sobre ellos. Sin tener que escribir mucho código, un importador y un analizador nosotros mismos, hay una herramienta fantástica para analizar esos archivos llamada Memlab.

Y Memlab es mantenido por Meta Open Source, y es un paquete completo para el análisis de memoria. Por ejemplo, se puede utilizar para detectar automáticamente fugas de memoria en tu aplicación, o incluso puede ejecutarse en tuberías de CI para verificar periódicamente tu uso de memoria, lo cual es realmente genial.

Otra característica interesante de Memlab es que puedes usarlo como un marco para realizar análisis en instantáneas del heap. De hecho, puedes escribir tu propio plugin de análisis usando JavaScript. He desarrollado algunos que me ayudaron a entender mejor la huella de memoria de mi aplicación. Y compartiré el código de esos para que otras personas también puedan usarlos.

Y el primer analizador que hice fue para responder a la pregunta, ¿qué tipos de objetos están ocupando más espacio de los dos millones que encontramos en una instantánea? Y para responder a esta pregunta, escribí este plugin de analizador que carga la instantánea del heap, agrupa los objetos por tipo, por el nombre de las propiedades que tienen dentro, y acumula su tamaño juntos, ordenándolos por mayor tamaño primero. De esta manera espero darle sentido a los cientos de megabytes que están siendo ocupados por objetos más pequeños.

Ejecuté el análisis en una instantánea de mi aplicación y los resultados que obtuve fueron realmente interesantes. El tipo de objetos que ocupaba el mayor tamaño en la aplicación tenía esta forma, con nombres de propiedades, base queue, base state, memorize state, next state, next end queue. No era un objeto que formaba parte de mi aplicación, pero me preguntaba de dónde venía. Y en realidad venía de los canales del marco de React. Y así es como funcionan internamente los hooks de React. De hecho, cada componente de React que se renderiza mantiene su información de estado en una estructura de datos llamada nodo de fibra. Cada objeto de nodo de fibra contiene una propiedad de estado memorizado, que es un puntero a una lista enlazada que contiene toda la información sobre tus hooks. Cada vez que realizas una llamada de hook en tu componente de React, se asigna un nuevo objeto de ese tipo y se añade a la propiedad next en esa lista enlazada. El valor de ese hook se almacena entonces en la propiedad de estado memorizado del nodo de la lista enlazada. Esta estructura de datos es utilizada por React cuando necesita renderizar ese componente, ya que puede recorrer la lista enlazada con cada llamada de hook, como useState, useMemo, useCallback, y obtener el valor que necesita devolver. Y por eso el orden de las llamadas de hook importa.

Al leer estos resultados del análisis del heap, obtuvimos una visión interesante. Los useMemos y los hooks son costosos, pero no por la razón que podrías pensar. No es realmente el contenido del valor memorizado en sí el que está ocupando mucho espacio, sino más bien todas las estructuras de soporte que son necesarias para que el hook funcione. Así que a partir de esto, obtuvimos una estrategia. Simplificar, fusionar, eliminar todos los hooks que tenemos en el camino crítico, y reducirlos tanto como sea posible. La gran pregunta, sin embargo, era cuáles componentes de React son los más pesados, y necesitamos optimizar primero para obtener el mayor beneficio de memoria. Para responder a esta pregunta, escribimos otro analizador de Memlab, que hizo las siguientes cosas. Primero, encuentra todas las estructuras de datos Fibernode en la instantánea de memoria. Para cada Fibernode, determina a qué componente de React pertenece mirando la propiedad de tipo. Luego calcula estadísticas sobre ese Fibernode, como qué hooks estaba utilizando y cuánta memoria estaba ocupando y luego acumula todas las estadísticas calculadas, agrupándolas por Tipo de Componente de React. Y al hacer esto, finalmente pudimos entender cuáles componentes de React eran los más pesados en términos de uso de memoria.

Lo utilizamos para decidir qué optimizar primero. Y después de optimizar incluso solo el primero de la lista, los componentes de React más pesados que teníamos, pudimos reducir en un 50% el uso de memoria en nuestra aplicación. Y ahora también puedes intentar hacer lo mismo con tu código si tienes problemas de memoria con el código que vamos a publicar.

Luego usamos Memlab para responder a otras preguntas que teníamos sobre nuestro uso de memoria. Una, por ejemplo, era sobre las asignaciones de memoria de las cadenas. De todas las cadenas que teníamos, ¿cuántas de ellas eran UIDs? ¿Deberíamos pasar de UIDs de cadena a UIDs numéricos? Bueno, el analizador de Memlab que hicimos nos permitió obtener una respuesta a esa pregunta. Y en realidad descubrimos que podríamos haber ahorrado solo un par de megabytes, por lo que no valía la pena por ahora.

Entonces, para resumir lo que aprendimos al analizar el uso de memoria. Lo primero es que el análisis de memoria es difícil y a veces la optimización que crees que mejorará las cosas puede salir mal. Por lo tanto, realizar análisis de este tipo ayuda mucho. Lo segundo es que el perfilador de Chrome es genial y es muy útil, pero a veces tienes que analizar las cosas más a fondo utilizando herramientas como Memlab que incluso es personalizable y puedes usarlo para responder tus propias preguntas. Y lo último es que los hooks de React no son baratos especialmente cuando tienes miles de instancias de los mismos componentes de React. Así que si estás construyendo algo grande con React, tenlo en cuenta. Y gracias por asistir a esta masterclass. Espero que esto te ayude a descubrir por qué tu aplicación está consumiendo tanta RAM. Y feliz perfilado.