Independientemente del tipo de aplicación que estés desarrollando, optimizar su rendimiento y garantizar que se cargue rápido y ofrezca interacciones fluidas es fundamental para la experiencia del usuario y el éxito de la aplicación. Una forma de hacerlo es inspeccionar la actividad de una aplicación con herramientas de generación de perfiles para ver qué sucede en segundo plano mientras se ejecuta durante un período determinado. El panel Rendimiento de DevTools es una excelente herramienta de generación de perfiles para analizar y optimizar el rendimiento de las aplicaciones web. Si tu app se ejecuta en Chrome, te brinda una descripción general visual detallada de lo que hace el navegador mientras se ejecuta la aplicación. Comprender esta actividad puede ayudarte a identificar patrones, cuellos de botella y puntos de rendimiento en los que puedes actuar para mejorar el rendimiento.
En el siguiente ejemplo, se explica cómo usar el panel Rendimiento.
Configuramos y recreamos nuestra situación de perfil
Recientemente, nos propusimos mejorar el rendimiento del panel Rendimiento. En particular, queríamos que cargara grandes volúmenes de datos de rendimiento más rápido. Este es el caso, por ejemplo, cuando se genera perfiles de procesos complejos o de larga duración, o cuando se capturan datos de alta granularidad. Para lograrlo, primero fue necesario comprender cómo se desempeñaba la aplicación y por qué lo hacía de esa manera, lo que se logró con una herramienta de generación de perfiles.
Como sabes, DevTools es una aplicación web. Por lo tanto, se puede generar un perfil con el panel Rendimiento. Para generar un perfil de este panel, puedes abrir DevTools y, luego, abrir otra instancia de DevTools conectada a él. En Google, esta configuración se conoce como DevTools en DevTools.
Con la configuración lista, se debe volver a crear y grabar la situación para la que se creará el perfil. Para evitar confusiones, la ventana original de DevTools se denominará "primera instancia de DevTools" y la ventana que inspecciona la primera instancia se denominará "segunda instancia de DevTools".
En la segunda instancia de DevTools, el panel Rendimiento (que se llamará panel de rendimiento de ahora en adelante) observa la primera instancia de DevTools para recrear la situación, que carga un perfil.
En la segunda instancia de DevTools, se inicia una grabación en vivo, mientras que en la primera instancia, se carga un perfil desde un archivo en el disco. Se carga un archivo grande para perfilar con precisión el rendimiento del procesamiento de entradas grandes. Cuando ambas instancias terminan de cargarse, los datos de perfil de rendimiento, comúnmente llamados seguimiento, se ven en la segunda instancia de DevTools del panel de rendimiento que carga un perfil.
El estado inicial: identificar oportunidades de mejora
Después de que se completó la carga, se observó lo siguiente en nuestra segunda instancia del panel de rendimiento en la siguiente captura de pantalla. Enfócate en la actividad del subproceso principal, que se puede ver en la pista etiquetada como Main. Se puede ver que hay cinco grandes grupos de actividad en el gráfico de llama. Estas consisten en las tareas en las que la carga tarda más tiempo. El tiempo total de estas tareas fue de aproximadamente 10 segundos. En la siguiente captura de pantalla, se usa el panel de rendimiento para enfocarse en cada uno de estos grupos de actividades y ver qué se puede encontrar.
Primer grupo de actividades: trabajo innecesario
Se hizo evidente que el primer grupo de actividades era código heredado que aún se ejecutaba, pero que en realidad no era necesario. Básicamente, todo lo que se encuentra debajo del bloque verde etiquetado como processThreadEvents fue un esfuerzo desperdiciado. Eso fue un éxito rápido. Quitar esa llamada a función ahorró alrededor de 1.5 segundos. Genial.
Segundo grupo de actividades
En el segundo grupo de actividades, la solución no fue tan simple como en el primero. La buildProfileCalls tardó alrededor de 0.5 segundos, y esa tarea no se podía evitar.
Por curiosidad, habilitamos la opción Memoria en el panel de rendimiento para investigar más y vimos que la actividad buildProfileCalls también usaba mucha memoria. Aquí, puedes ver cómo el gráfico de línea azul salta repentinamente alrededor del momento en que se ejecuta buildProfileCalls, lo que sugiere una posible fuga de memoria.
Para investigar esta sospecha, usamos el panel Memory (otro panel de DevTools, diferente del panel Memory del panel de rendimiento) para investigar. En el panel Memoria, se seleccionó el tipo de generación de perfiles "Muestreo de asignación", que registró la instantánea del montón para que el panel de rendimiento cargue el perfil de CPU.
En la siguiente captura de pantalla, se muestra la instantánea del montón que se recopiló.
A partir de esta instantánea del montón, se observó que la clase Set consumía mucha memoria. Cuando revisamos los puntos de llamada, descubrimos que estábamos asignando propiedades de tipo Set de forma innecesaria a objetos que se crearon en grandes volúmenes. Este costo se acumulaba y se consumía mucha memoria, hasta el punto de que era común que la aplicación fallara en entradas grandes.
Los conjuntos son útiles para almacenar elementos únicos y proporcionar operaciones que usan la unicidad de su contenido, como anular la duplicación de conjuntos de datos y proporcionar búsquedas más eficientes. Sin embargo, esas funciones no eran necesarias, ya que se garantizaba que los datos almacenados fueran únicos de la fuente. Por lo tanto, los conjuntos no eran necesarios en primer lugar. Para mejorar la asignación de memoria, se cambió el tipo de propiedad de Set a un array simple. Después de aplicar este cambio, se tomó otra instantánea del montón y se observó una reducción en la asignación de memoria. A pesar de no lograr mejoras considerables en la velocidad con este cambio, el beneficio secundario fue que la aplicación fallaba con menos frecuencia.
Tercer grupo de actividades: sopesar las compensaciones de la estructura de datos
La tercera sección es peculiar: puedes ver en el gráfico de llama que consta de columnas estrechas pero altas, que denotan llamadas a funciones profundas y recursión profunda en este caso. En total, esta sección duró alrededor de 1.4 segundos. Cuando miré la parte inferior de esta sección, noté que el ancho de estas columnas estaba determinado por la duración de una función: appendEventAtLevel, lo que sugería que podría ser un cuello de botella.
Dentro de la implementación de la función appendEventAtLevel, se destacó una cosa. Para cada entrada de datos en la entrada (que se conoce en el código como "evento"), se agregó un elemento a un mapa que hacía un seguimiento de la posición vertical de las entradas de la línea de tiempo. Esto era un problema, ya que la cantidad de elementos almacenados era muy grande. Los mapas son rápidos para las búsquedas basadas en claves, pero esta ventaja no es gratuita. A medida que un mapa crece, agregarle datos puede, por ejemplo, volverse costoso debido al reescritura. Este costo se hace evidente cuando se agregan grandes cantidades de elementos al mapa de forma sucesiva.
/**
* Adds an event to the flame chart data at a defined vertical level.
*/
function appendEventAtLevel (event, level) {
// ...
const index = data.length;
data.push(event);
this.indexForEventMap.set(event, index);
// ...
}
Experimentamos con otro enfoque que no requería que agreguemos un elemento en un mapa para cada entrada del gráfico de llama. La mejora fue significativa, lo que confirmó que el cuello de botella se relacionaba con la sobrecarga que se generaba cuando se agregaban todos los datos al mapa. El tiempo que tardó el grupo de actividades disminuyó de alrededor de 1.4 segundos a alrededor de 200 milisegundos.
Antes:
Después:
Cuarto grupo de actividades: Aplaza el trabajo no crítico y almacena en caché los datos para evitar el trabajo duplicado
Si acercas la imagen en esta ventana, puedes ver que hay dos bloques de llamadas a función casi idénticos. Si observas el nombre de las funciones a las que se llama, puedes inferir que estos bloques consisten en código que crea árboles (por ejemplo, con nombres como refreshTree o buildChildren). De hecho, el código relacionado es el que crea las vistas de árbol en el panel inferior del panel. Lo interesante es que estas vistas de árbol no se muestran justo después de la carga. En su lugar, el usuario debe seleccionar una vista de árbol (las pestañas "De abajo hacia arriba", "Árbol de llamadas" y "Registro de eventos" en el panel lateral) para que se muestren los árboles. Además, como puedes ver en la captura de pantalla, el proceso de compilación del árbol se ejecutó dos veces.
Identificamos dos problemas con esta foto:
- Una tarea no esencial estaba obstaculizando el rendimiento del tiempo de carga. Los usuarios no siempre necesitan su salida. Por lo tanto, la tarea no es fundamental para la carga del perfil.
- El resultado de estas tareas no se almacenó en caché. Por eso, los árboles se calcularon dos veces, a pesar de que los datos no cambiaron.
Comenzamos con aplazar el cálculo del árbol hasta que el usuario abrió manualmente la vista de árbol. Solo entonces vale la pena pagar el precio de crear estos árboles. El tiempo total de ejecución de esta operación dos veces fue de alrededor de 3.4 segundos, por lo que aplazarla marcó una diferencia significativa en el tiempo de carga. También estamos analizando la posibilidad de almacenar en caché estos tipos de tareas.
Quinto grupo de actividades: Evita las jerarquías de llamadas complejas siempre que sea posible
Al observar este grupo con detenimiento, quedó claro que se invocaba una cadena de llamadas en particular de forma reiterada. El mismo patrón apareció 6 veces en diferentes lugares del gráfico de llama, y la duración total de esta ventana fue de aproximadamente 2.4 segundos.
El código relacionado al que se llama varias veces es la parte que procesa los datos que se renderizarán en el "minimapa" (la descripción general de la actividad de la ruta en la parte superior del panel). No estaba claro por qué sucedía varias veces, pero no tenía que suceder 6 veces. De hecho, el resultado del código debería permanecer actualizado si no se carga ningún otro perfil. En teoría, el código solo debería ejecutarse una vez.
Después de la investigación, se descubrió que se llamó al código relacionado como consecuencia de que varias partes de la canalización de carga llamaban directa o indirectamente a la función que calcula el minimapa. Esto se debe a que la complejidad del gráfico de llamadas del programa evolucionó con el tiempo y se agregaron más dependencias a este código sin saberlo. No hay una solución rápida para este problema. La forma de resolverlo depende de la arquitectura de la base de código en cuestión. En nuestro caso, tuvimos que reducir un poco la complejidad de la jerarquía de llamadas y agregar una verificación para evitar la ejecución del código si los datos de entrada no se modificaban. Después de implementar esto, obtuvimos este panorama del cronograma:
Ten en cuenta que la ejecución de renderización del minimapa se produce dos veces, no una. Esto se debe a que se dibujan dos minimapas para cada perfil: uno para la descripción general en la parte superior del panel y otro para el menú desplegable que selecciona el perfil visible actualmente del historial (cada elemento de este menú contiene una descripción general del perfil que selecciona). Sin embargo, ambos tienen exactamente el mismo contenido, por lo que se debería poder reutilizar uno para el otro.
Dado que estos minimapas son imágenes dibujadas en un lienzo, solo fue cuestión de usar la utilidad de lienzo drawImage y, luego, ejecutar el código solo una vez para ahorrar tiempo. Como resultado de este esfuerzo, la duración del grupo se redujo de 2.4 segundos a 140 milisegundos.
Conclusión
Después de aplicar todas estas correcciones (y algunas otras más pequeñas aquí y allá), el cambio del cronograma de carga del perfil se veía de la siguiente manera:
Antes:
Después:
El tiempo de carga después de las mejoras fue de 2 segundos, lo que significa que se logró una mejora de alrededor del 80% con un esfuerzo relativamente bajo, ya que la mayor parte de lo que se hizo consistió en correcciones rápidas. Por supuesto, identificar correctamente qué hacer al principio fue clave, y el panel de rendimiento fue la herramienta adecuada para esto.
También es importante destacar que estas cifras son particulares de un perfil que se usa como sujeto de estudio. El perfil nos interesó porque era muy grande. Sin embargo, como la canalización de procesamiento es la misma para cada perfil, la mejora significativa que se logra se aplica a cada perfil cargado en el panel de rendimiento.
Conclusiones
Existen algunas lecciones que se pueden extraer de estos resultados en términos de optimización del rendimiento de tu aplicación:
1. Usa herramientas de generación de perfiles para identificar patrones de rendimiento del entorno de ejecución
Las herramientas de generación de perfiles son muy útiles para comprender lo que sucede en tu aplicación mientras se ejecuta, en especial para identificar oportunidades de mejora del rendimiento. El panel Rendimiento en Chrome DevTools es una excelente opción para las aplicaciones web, ya que es la herramienta de generación de perfiles web nativa del navegador y se mantiene de forma activa para estar al día con las funciones más recientes de la plataforma web. Además, ahora es mucho más rápida. 😉
Usa muestras que se puedan usar como cargas de trabajo representativas y descubre qué puedes encontrar.
2. Evita jerarquías de llamadas complejas
Cuando sea posible, evita que el gráfico de llamadas sea demasiado complicado. Con jerarquías de llamadas complejas, es fácil introducir regresiones de rendimiento y difícil comprender por qué tu código se ejecuta de la forma en que lo hace, lo que dificulta la implementación de mejoras.
3. Identifica el trabajo innecesario
Es común que las bases de código antiguas contengan código que ya no es necesario. En nuestro caso, el código heredado y no necesario ocupaba una parte significativa del tiempo de carga total. Quitarlo fue la opción más fácil.
4. Usa estructuras de datos de forma adecuada
Usa estructuras de datos para optimizar el rendimiento, pero también comprende los costos y las compensaciones que cada tipo de estructura de datos conlleva cuando decidas cuáles usar. Esto no solo incluye la complejidad espacial de la estructura de datos en sí, sino también la complejidad temporal de las operaciones aplicables.
5. Almacena en caché los resultados para evitar el trabajo duplicado en operaciones complejas o repetitivas
Si la operación es costosa de ejecutar, tiene sentido almacenar sus resultados para la próxima vez que se necesite. También tiene sentido hacerlo si la operación se realiza muchas veces, incluso si cada vez no es particularmente costosa.
6. Aplaza el trabajo que no sea fundamental
Si no se necesita de inmediato el resultado de una tarea y la ejecución de la tarea extiende la ruta crítica, considera aplazarla llamándola de forma diferida cuando realmente se necesite su resultado.
7. Usa algoritmos eficientes en entradas grandes
En el caso de las entradas grandes, los algoritmos de complejidad temporal óptimos se vuelven fundamentales. No analizamos esta categoría en este ejemplo, pero su importancia es innegable.
8. Bonificación: Compara tus canalizaciones
Para asegurarte de que tu código en evolución siga siendo rápido, es conveniente supervisar el comportamiento y compararlo con los estándares. De esta manera, identificas de forma proactiva las regresiones y mejoras la confiabilidad general, lo que te permite alcanzar el éxito a largo plazo.