¿Tu App WebAssembly va como un F1... pero con el freno de mano puesto?

¿Alguna vez has sentido que tu app WebAssembly va como un F1... pero con el freno de mano puesto? El renderizado va fluido, la lógica responde, pero algo raro hace que todo se sienta lento. Y lo peor: no tienes ni idea de por qué.

Aquí está el problema: ya no puedes culpar a JavaScript. Tu código Wasm corre a velocidad casi nativa, pero cuando algo se atasca, el navegador se convierte en una caja negra. Las herramientas de perfilado tradicionales se quedan cortas, y si no quieres depender de Rust o Python para instrumentar tu código, la cosa se complica.

Pero tranquila, que para eso estoy yo. Hoy vamos a desmontar el mito de que perfilar Wasm es imposible sin herramientas de compilación exóticas. Vamos a ver cómo usar el trazado de llamadas directamente en el navegador para encontrar esos cuellos de botella que te están robando frames y segundos de carga.

El problema: tu Wasm es una caja negra (y no, no es culpa tuya)

Cuando escribes en JavaScript, abres las DevTools y ves cada función, cada llamada, cada milisegundo. Es como tener rayos X. Pero con Wasm, el navegador te muestra un binario opaco que parece un jeroglífico.

Las herramientas de perfilado del navegador han mejorado mucho, pero siguen tratando a Wasm como un ciudadano de segunda clase. Los stack traces a veces salen vacíos o con nombres crípticos. Y si tu lógica de negocio está compilada desde C++ o Rust, olvídate de ver nombres de funciones útiles.

La solución que mucha gente elige es instrumentar el código en el lenguaje fuente. Pero eso significa recompilar, mantener dos versiones de tu código, y básicamente convertir tu pipeline de desarrollo en un infierno. Hay una forma mejor.

El trazado de llamadas en el navegador: tu nuevo mejor amigo

La API de rendimiento del navegador (performance.now() y compañía) es tu primera línea de defensa. Puedes marcar el inicio y fin de tus funciones Wasm manualmente, pero eso es como arreglar un agujero en el barco con chicle.

Lo que realmente necesitas es el muestreo de la pila de llamadas (stack sampling). El navegador ya lo hace para JavaScript, y con Wasm, las versiones modernas de las DevTools pueden mapear las direcciones de memoria a símbolos si compilas con información de depuración.

Aquí está el truco: compila tu código Wasm con -g y con names sections. No, no es magia, es simplemente darle al navegador el mapa del tesoro. Con esto, el perfilador te mostrará nombres de funciones reales, no direcciones hexagonales que parecen un código secreto.

Renderizado vs. Lógica: separando el grano de la paja

El primer cuello de botella que vas a encontrar es el renderizado. Tu Wasm puede estar haciendo cálculos pesados, pero si el resultado no llega al DOM de forma eficiente, todo se va al carajo.

La clave está en el trazado de llamadas entre Wasm y JavaScript. Cuando tu código Wasm llama a una función JS para actualizar el DOM, ahí hay un punto de fricción. Cada cruce de frontera tiene un coste, y si estás haciendo miles de llamadas pequeñas, el rendimiento se desploma.

Usa el perfilador para ver cuánto tiempo pasa tu Wasm dentro de funciones de renderizado vs. en lógica pura. Si ves que el 80% del tiempo está en llamadas a document.createElement o manipulando el DOM, el problema no es tu algoritmo, es cómo comunicas los resultados.

El caso de la lógica de negocio: cuando el cuello de botella eres tú

Ahora, la parte que nadie quiere admitir: a veces el problema no es el renderizado, es tu lógica. Y no, no me refiero a que tu algoritmo sea malo (aunque a veces lo es). Me refiero a que estás haciendo cosas que no deberías en el hilo principal.

El perfilador te va a mostrar si tu Wasm está haciendo operaciones síncronas largas que bloquean el hilo. Si ves que una función tarda 200ms y se llama en cada frame, tienes un problema de diseño, no de rendimiento.

La solución no es optimizar esa función (aunque también), es moverla a un Web Worker. Sí, ya sé que con Wasm los threads son complicados, pero hay formas de manejarlo. El perfilador te dirá exactamente qué funciones son las culpables, y luego tú decides si las paralelizas o si cambias la arquitectura.

Las herramientas que tienes (y las que no necesitas)

Vamos a ser honestas: no necesitas instalar nada raro. Las DevTools de tu navegador tienen un perfilador de rendimiento que funciona con Wasm, siempre que compiles con los símbolos adecuados.

El truco está en la vista de "Bottom-Up" (de abajo hacia arriba). Te muestra qué funciones consumen más tiempo, independientemente de quién las llame. Esto es oro puro para encontrar cuellos de botella en lógica de negocio, porque te dice exactamente dónde pasa el tiempo, no dónde empieza.

También puedes usar la vista de "Call Tree" (árbol de llamadas) para ver la cadena completa. Pero cuidado: con Wasm, a veces los nombres aparecen como wasm-function[123]. Si eso pasa, es que no compilaste con los símbolos. Vuelve atrás y arregla eso antes de seguir.

Mi recomendación (y sí, tengo opinión)

Empieza por lo simple: compila con símbolos, abre el perfilador, y mira la vista Bottom-Up. No te obsesiones con optimizar todo: busca las funciones que consumen más del 20% del tiempo y concéntrate en esas.

Y aquí viene mi opinión impopular: no necesitas Rust ni Python para perfilar tu Wasm. Esas herramientas son geniales para desarrollo, pero para depurar en el navegador, las herramientas nativas son suficientes. Si tu problema es tan complejo que necesitas instrumentación externa, probablemente tienes un problema de arquitectura, no de rendimiento.

El futuro del perfilado Wasm es prometedor. Se está trabajando en herramientas más maduras, y los navegadores están mejorando su soporte. Pero hoy, con lo que tienes, puedes hacer maravillas. Solo necesitas saber dónde mirar.

Y ahora, dime: ¿cuál es el cuello de botella más raro que has encontrado en tu app Wasm? ¿Fue el renderizado, la lógica, o algo completamente inesperado? Cuéntamelo en los comentarios, que me muero de curiosidad.