Rust

(danielchasehooper.com)

20 puntos por GN⁺ 2025-08-16 | Aún no hay comentarios. | Compartir por WhatsApp

What the Fork es una herramienta multiplataforma que visualiza en tiempo real distintos procesos de build, como los de C/C++/Rust
Permite identificar fácilmente problemas estructurales de los sistemas de build existentes, como falta de paralelismo y procesos ineficientes
Funciona con todos los sistemas de build y lenguajes de programación, con soporte para diversas herramientas de build como make, ninja, gradle, zig y cargo
Mediante monitoreo de llamadas al sistema, visualiza en forma de cajas el tiempo de ejecución, los comandos y las dependencias de cada proceso
Es una herramienta muy útil para optimizar builds, analizar cuellos de botella y mejorar el rendimiento de CI

Introducción y contexto

What the Fork es una herramienta de visualización de builds en tiempo real desarrollada para diagnosticar visualmente por qué un build se vuelve lento
En proyectos como LLVM, la compilación puede ser lenta simplemente por el gran volumen de código, pero en la mayoría de los casos los builds tardan más de lo necesario debido a configuraciones ineficientes
Hasta ahora era difícil revisar directamente los problemas de un build o ver de un vistazo los problemas estructurales, por eso hacía falta una herramienta así
Esta herramienta fue diseñada para ser multiplataforma y se puede aplicar a cualquier sistema de build y lenguaje

What the Fork no es un simple profiler del sistema, sino una herramienta enfocada en diagnosticar problemas específicos de builds
Algunos ejemplos son detectar el no uso de la bandera -j con make, concentración de tiempo en un archivo o etapa de compilación concreta, y comandos que se ejecutan en secuencia aunque podrían procesarse en paralelo
Es especialmente eficaz para analizar y optimizar el rendimiento de clean builds en entornos de CI
Se usa anteponiendo el comando wtf al comando de build (por ejemplo: wtf make, wtf cargo build, wtf npm run build)
Cuando empieza el build, se abre la UI y actualiza en tiempo real el progreso de cada proceso

Cada proceso de build se muestra como una caja en una línea de tiempo y se diferencia por color según su tipo
La relación padre-hijo entre procesos se representa con una estructura anidada
En el panel inferior se muestran el tiempo de ejecución, el directorio de trabajo y los argumentos completos del comando del proceso seleccionado

Un build es una combinación de varios procesos (por ejemplo: bash, clang, ld)
Los builds de gran escala usan distintas herramientas como cargo, make, bazel, gradle y xcodebuild, que en la práctica ejecutan muchos comandos, dependencias, cachés y tareas de scheduling
Solo con la salida de la terminal no es posible entender la estructura detallada de tiempos ni los procesos anidados (por ejemplo, ld invocado internamente por clang)
Para resolver esto, aprovecha llamadas al sistema que detectan el inicio y fin de procesos según el sistema operativo (macOS: Endpoint Security API, Linux: ptrace(), Windows: Event Tracing for Windows)
De esta manera, puede reconstruir todo el proceso de build y su línea de tiempo, e identificar la ruta de ejecución y el tiempo de cada etapa
También puede usarse para rastrear distintos subprocesos más allá de los builds

Varios ingenieros (de Delta, Mozilla y Apple) lo aplicaron en proyectos reales y encontraron problemas inesperados
Ejemplo 1: en un proyecto open source que usa Cargo, se confirmó falta de paralelismo porque los archivos se compilaban secuencialmente (en una CPU de 10 núcleos se observó potencial para una mejora de más de 10 veces)
Ejemplo 2: en un build de LLVM con Ninja, todos los núcleos de CPU trabajaban en paralelo de forma eficiente, logrando una eficiencia de build ideal
Ejemplo 3: en un proyecto basado en CMake, se detectó una estructura ineficiente con ejecuciones anidadas de cmake/make/clang y 85 repeticiones de verificación de versión de Xcode/OS, donde el trabajo real era mínimo
Ejemplo 4: en un gran proyecto Objective-C con xcodebuild, se observó falta de paralelismo en la fase final del build y un período inactivo de 6 segundos antes de comenzar; en comparación, ninja empezaba a compilar casi de inmediato, tras 0.4 segundos
Ejemplo 5: al compilar Orca Project con Zig, el orden de build de las dependencias se determinaba de forma aleatoria, por lo que la eficiencia del paralelismo cambiaba según la suerte. Se observó que algunas dependencias se ejecutaban al final y reducían el paralelismo
Ejemplo 6: en el proyecto GitHub CLI con make/go, el tiempo de descarga de dependencias era elevado. Reducir las dependencias podría mejorar la velocidad del build

El análisis visual de la línea de tiempo permite identificar cuellos de botella inesperados, repeticiones innecesarias de dependencias y áreas con poco paralelismo
Permite detectar rápidamente oportunidades de mejora estructural, como problemas de dependencias, retrabajo innecesario o ineficiencias de herramientas concretas, y aplicarlas directamente a la optimización del rendimiento del build
Ver el comando completo de cada proceso permite un análisis más detallado

What the Fork funciona en Windows, Linux y macOS
Las personas y equipos que quieran dar feedback pueden solicitar acceso a la beta privada (se proporciona un enlace a Google Forms)