Un perfilador de compilaciones open source para ver dónde se va el tiempo en Linux
buildprof registra el árbol de procesos de cualquier build y lo dibuja en una línea de tiempo. Su autor lo usó para diseccionar por qué la compilación de Bun en Zig tardaba 24 minutos.
buildprof es una herramienta de trazado open source que registra cada proceso que lanza una compilación en Linux y los coloca sobre una misma línea de tiempo. Se usa anteponiéndola al comando de build que ya tengas: buildprof -- make -j16, buildprof -- cargo build, buildprof -- ninja -C out/target o buildprof -- ./dev/custom-build-script.sh. El código está en GitHub y hay una demo grabando un build limpio de ripgrep.
El enfoque apunta a la capa de procesos, no a la del sistema de compilación. Desde el punto de vista del sistema operativo, cargo, ninja, zig o make hacen más o menos lo mismo: lanzan programas que lanzan otros programas. Una cadena típica en Rust sería cargo, rustc, cc, collect2 y ld.lld. Eso tiene dos consecuencias prácticas: la herramienta es agnóstica del build system —no hay que escribir una integración para cada uno— y captura también los scripts propios, tanto los de preparación del repositorio y descarga de dependencias como los generadores de código que cuelgan por debajo.
En la interfaz, el tiempo corre de izquierda a derecha, el ancho de cada barra es su duración y los procesos hijos aparecen debajo de quien los lanzó. Como además se registran los archivos que lee y escribe cada proceso, se puede seguir qué paso produce la entrada del siguiente, incluso cruzando sistemas de compilación distintos. La utilidad es la de siempre: cuando un build es lento no suele ser porque haya mucho código, sino por paralelismo pobre, trabajo repetido, descargas de dependencias o una invocación de compilador o enlazador desproporcionada.
El caso Bun
El motivo de construir la herramienta fue una afirmación de Jarred Sumner, arquitecto jefe del runtime de JavaScript Bun: que el nuevo build en Rust era más de 5 veces más rápido en Linux que el antiguo en Zig. La cifra le chocó, porque en su experiencia los proyectos Zig compilaban bastante más rápido que proyectos Rust de complejidad similar.
Reprodujo los números sobre Bun 1.3.14 y Bun 1.4.0, replicando los builds de CI de Linux x64 en una máquina virtual de 6 núcleos y 12 hilos. La mediana publicada por la CI de Bun era de 30m06s en la era Zig y 5m37s en la era Rust. En su repetición local salió 24m24s frente a 5m40s. La brecha aparecía también en su máquina.
La pista que siguió está en la propia comparación: el build de Zig usaba Full LTO y el de Rust, ThinLTO. El LTO permite optimizar entre unidades de compilación; Full LTO las junta en un único trabajo grande, mientras que ThinLTO conserva más separación y deja que buena parte del trabajo se paralelice. Al abrir el trazado del build de Zig, el enlazador ld.lld se comía más de dieciséis minutos él solo al final, cerca de dos tercios del total. Ahí estaba el sospechoso principal. El texto del autor se corta justo antes de confirmar cuánto de ese tiempo era atribuible al LTO y cuánto a otras diferencias entre las dos épocas del proyecto.
Para quien mantiene pipelines de integración continua, la herramienta responde a una pregunta que los logs no contestan: no qué falló, sino dónde se fue el tiempo. Los scripts que usó para replicar los dos builds de Bun están publicados aparte.
