Leer un flame chart: la forma dice más que los números

El gráfico de llamas es la representación más densa de información de todas las DevTools y también la peor entendida, porque su forma invita a una lectura intuitiva que es incorrecta. La anchura no es importancia, la altura no es coste, y el color no es gravedad. Una vez que las tres correspondencias están claras, la silueta de un gráfico de llamas se lee como un diagrama y responde en diez segundos preguntas que de otra forma exigen leer cientos de nombres de función.

Los tres ejes de información

El eje horizontal es el tiempo, y solo el tiempo. Cada caja empieza donde empezó esa llamada y termina donde terminó. La anchura de una caja es su duración total, incluyendo todo lo que llamó. Dos cajas contiguas no tienen relación entre sí más allá de haberse ejecutado una después de otra.

El eje vertical es la profundidad de la pila. Una caja debajo de otra significa “fue llamada por”. La profundidad no dice nada sobre el coste: una pila de cuarenta niveles puede durar un microsegundo y una caja solitaria de primer nivel puede durar dos segundos. Lo que sí dice la profundidad es cuánta indirección hay, y una pila muy profunda con muchas capas de librería explica por qué un trabajo aparentemente simple tarda.

El color agrupa por categoría de trabajo, no por gravedad. Script, estilo, disposición, pintado y sistema tienen colores distintos, y ese es todo el significado. Un bloque de un color intenso no es peor que uno de otro. Lo que sí es informativo es el reparto de colores: un gráfico monocromático de script y otro con franjas alternas de estilo y disposición son dos problemas distintos.

Las cinco siluetas

La torre. Una pila alta y estrecha que se mantiene con la misma anchura durante varios niveles. Significa una cadena de llamadas donde cada una delega en la siguiente sin hacer casi nada por su cuenta. El coste está en la hoja del fondo. Es la forma típica de una llamada que atraviesa varias capas de abstracción para acabar en una operación cara.

La meseta. Una caja muy ancha en un nivel bajo, casi sin nada encima. Significa una función que hace el trabajo ella misma en lugar de delegarlo: un bucle grande, un análisis sintáctico, una serialización. Es la silueta más fácil de optimizar porque el culpable es evidente.

El peine. Decenas o cientos de cajas idénticas, estrechas, una detrás de otra en el mismo nivel. Significa una operación repetida muchas veces. El coste individual es despreciable y el agregado enorme. Es la silueta que el gráfico de llamas muestra mal y la vista de abajo arriba muestra bien, porque suma todas las apariciones.

La escalera. Cajas que descienden de nivel progresivamente, cada una empezando donde acaba la anterior. Es recursión o iteración con acumulación de pila. Con frecuencia indica un algoritmo con complejidad peor de la que se supone.

El bosque. Muchos árboles independientes, cada uno con su propia raíz, sin un patrón claro. Es lo que produce un perfil de una aplicación real bajo carga normal, y no indica nada por sí mismo. Si el gráfico parece un bosque, la respuesta no está en la forma sino en las vistas agregadas del panel inferior.

Tiempo propio frente a tiempo total

Esta es la distinción que hay que interiorizar para no perder tardes acusando al marco equivocado.

El tiempo total de una función es todo lo que transcurrió entre su entrada y su salida, incluidas las llamadas anidadas. Es la anchura de su caja.

El tiempo propio es lo que se ejecutó en su cuerpo sin contar las llamadas anidadas. Visualmente es la parte de su caja que no está tapada por cajas hijas.

Una función con un tiempo total de ochocientos milisegundos y un tiempo propio de dos no es lenta: es una función que espera a otras. Optimizarla es imposible porque no hace nada. La vista de abajo arriba ordena precisamente por tiempo propio, y por eso es la vista que encuentra al culpable real.

El fragmento siguiente ilustra la diferencia con un caso construido, y sirve para practicar la lectura sobre un perfil propio. Pégalo en la consola con el panel grabando.

// Genera tres siluetas reconocibles en el grafico de llamas
(() => {
  const quemar = ms => { const t = performance.now(); while (performance.now() - t < ms); };

  // 1. La torre: cadena de delegacion que acaba en una hoja cara
  const nivel4 = () => quemar(120);
  const nivel3 = () => nivel4();
  const nivel2 = () => nivel3();
  const nivel1 = () => nivel2();

  // 2. La meseta: una sola funcion que hace todo el trabajo
  const meseta = () => {
    let x = 0;
    for (let i = 0; i < 8e6; i++) x += Math.sqrt(i) % 7;
    return x;
  };

  // 3. El peine: una operacion barata repetida muchas veces
  const dienteDelPeine = i => { const t = performance.now(); while (performance.now() - t < 0.4) {} return i; };
  const peine = () => { for (let i = 0; i < 300; i++) dienteDelPeine(i); };

  console.time('torre');  nivel1();  console.timeEnd('torre');
  console.time('meseta'); meseta();  console.timeEnd('meseta');
  console.time('peine');  peine();   console.timeEnd('peine');
})();

Al leer el perfil resultante, comprueba las tres cosas: en la torre, el tiempo propio está concentrado en la hoja y los tres niveles superiores tienen tiempo propio casi cero. En la meseta, el tiempo propio y el total coinciden. Y en el peine, ninguna caja individual llama la atención mientras que la vista de abajo arriba muestra la función repetida en el primer puesto.

Subir hasta el marco accionable

Encontrar la función que consume tiempo es la mitad del trabajo. La otra mitad es encontrar el punto donde puedes intervenir, que casi nunca es el mismo sitio.

Si el tiempo propio está en una función interna del navegador —recálculo de estilo, análisis del HTML, decodificación de una imagen— no hay nada que optimizar ahí dentro. Lo accionable es quién la provocó y por qué, y eso está unos niveles más arriba.

Si el tiempo propio está en una función de una librería, tampoco vas a modificarla. Lo accionable es la llamada de tu código que la invoca, cómo la invoca y cuántas veces.

El procedimiento es subir nivel a nivel desde la hoja hasta encontrar el primer marco cuyo fichero esté bajo tu control, y hacerse tres preguntas sobre él: ¿esta llamada tenía que ocurrir? —muchas veces la mejor optimización es no hacerla—, ¿tenía que ocurrir ahora? —diferirla a un momento inactivo resuelve el problema sin tocar el coste— y ¿tenía que ocurrir tantas veces?.

Ese recorrido es mucho más rápido si la lista de ignorados está bien configurada, porque el panel colapsa los marcos de librería y deja visible tu código. Es la misma configuración de blackboxing que hace usable el depurador, y aquí hace usable el gráfico de llamas.