What the Fork - Alat visualisasi build C/C++/Rust secara real-time

• What the Fork adalah alat lintas platform yang memvisualisasikan berbagai proses build seperti C/C++/Rust secara real-time
• Memudahkan untuk memahami masalah struktural seperti kurangnya pemrosesan paralel dan proses yang tidak efisien pada sistem build yang ada
• Dapat berjalan pada semua sistem build dan bahasa pemrograman, serta mendukung berbagai alat build seperti make, ninja, gradle, zig, cargo, dan lainnya
• Melalui pemantauan system call, alat ini memvisualisasikan waktu eksekusi, perintah, dan hubungan dependensi tiap proses dalam bentuk kotak
• Sangat berguna untuk optimasi build, analisis bottleneck, dan peningkatan performa CI

---

Pengenalan dan latar belakang

• What the Fork adalah alat visualisasi build real-time yang dikembangkan untuk mendiagnosis secara visual penyebab build menjadi lambat
• Pada proyek seperti LLVM, kompilasi bisa lambat karena ukuran kode yang besar, tetapi pada kebanyakan build, waktu yang terlalu lama sering kali disebabkan oleh konfigurasi yang tidak efisien
• Sebelumnya, sulit untuk memeriksa masalah build secara langsung atau memahami persoalan strukturalnya dalam sekali lihat, sehingga alat seperti ini dibutuhkan
• Alat ini dirancang lintas platform dan dapat diterapkan pada semua sistem build dan bahasa

Fitur utama dan cara penggunaan

• What the Fork bukan sekadar profiler sistem biasa, melainkan alat untuk mendiagnosis masalah yang spesifik pada build
• Contohnya meliputi tidak digunakannya flag -j saat memakai make, konsentrasi waktu pada file atau tahap kompilasi tertentu, serta deteksi perintah yang berjalan berurutan padahal bisa diparalelkan
• Sangat efektif terutama untuk analisis dan optimasi performa clean build di lingkungan CI
• Cara pakainya adalah menjalankan perintah wtf di depan perintah build (misalnya wtf make, wtf cargo build, wtf npm run build, dan sebagainya)
• Saat build dimulai, UI akan berjalan dan memperbarui status tiap proses secara real-time

UI dan metode visualisasi

• Setiap proses build ditampilkan pada timeline dalam bentuk kotak, dengan warna berbeda sesuai jenisnya
• Hubungan parent-child antarproses direpresentasikan dalam struktur bertingkat
• Panel bawah menampilkan waktu eksekusi, direktori kerja, dan informasi lengkap argumen perintah dari proses yang dipilih

Cara kerja

• Build adalah gabungan dari banyak proses (misalnya bash, clang, ld)
• Build berskala besar menggunakan berbagai alat seperti cargo, make, bazel, gradle, xcodebuild, dan semuanya pada praktiknya menjalankan banyak perintah, dependensi, cache, dan penjadwalan
• Dari output terminal saja, tidak mungkin memahami proses bertingkat seperti proses internal (ld yang dipanggil dari clang, misalnya) maupun struktur timing yang rinci
• Untuk itu, alat ini memanfaatkan system call yang mendeteksi awal dan akhir proses pada tiap OS (macOS: Endpoint Security API, Linux: ptrace(), Windows: Event Tracing for Windows, dan lainnya)
• Dengan pendekatan ini, seluruh proses build dan timeline dapat direkonstruksi, sehingga jalur eksekusi dan waktu dari setiap tahap bisa diidentifikasi
• Selain build, alat ini juga dapat dimanfaatkan untuk melacak berbagai subprocess lain

Contoh nyata dan hasil pengamatan

• Beberapa engineer (dari Delta, Mozilla, dan Apple) benar-benar menerapkannya pada proyek mereka dan menemukan masalah yang tak terduga
• Contoh 1: Pada proyek open source yang menggunakan Cargo, file dikompilasi secara berurutan sehingga terlihat kurangnya paralelisme (pada CPU 10 core, ada potensi peningkatan kecepatan lebih dari 10x)
• Contoh 2: Pada build LLVM berbasis Ninja, semua core CPU menjalankan pekerjaan paralel secara efisien sehingga tercapai efisiensi build yang ideal
• Contoh 3: Pada proyek berbasis CMake, ditemukan struktur tidak efisien berupa eksekusi bertingkat cmake/make/clang serta pemeriksaan ulang versi Xcode/OS yang berulang sampai 85 kali (padahal pekerjaan sebenarnya sangat sedikit)
• Contoh 4: Pada proyek Objective-C besar yang memakai xcodebuild, terdeteksi kurangnya pemrosesan paralel pada fase akhir build dan adanya periode tidak aktif selama 6 detik sebelum build dimulai (sementara ninja mulai kompilasi hanya setelah 0,4 detik)
• Contoh 5: Saat Zig mengompilasi Orca Project, urutan build dependensi ditentukan secara acak sehingga efisiensi paralel berubah tergantung keberuntungan. Teramati bahwa beberapa dependensi berjalan paling akhir dan menurunkan paralelisme
• Contoh 6: Pada proyek GitHub CLI yang menggunakan make/go, waktu unduh dependensi sangat besar. Mengurangi dependensi diperkirakan dapat meningkatkan kecepatan build

Dampak penggunaan dan keterbatasan

• Melalui analisis timeline visual, pengguna dapat mengidentifikasi area bottleneck yang tak terduga, pengulangan dependensi yang tidak perlu, dan bagian yang kurang paralel
• Masalah dependensi, rework yang tidak perlu, dan inefisiensi pada alat tertentu dapat cepat dipahami sebagai titik perbaikan struktural, sehingga langsung berguna untuk optimasi performa build
• Melihat perintah lengkap tiap proses juga memungkinkan analisis yang lebih mendetail

Program beta

• What the Fork berjalan di Windows, Linux, dan macOS
• Individu dan tim yang ingin memberikan masukan dapat mendaftar ke private beta (tautan Google Form disediakan)

[brain1401]

Perintahnya lucu banget wkwkwk, masa wtf sih…

[t7vonn]

Akan bagus kalau dirilis sebagai open source.

[GN⁺]

Opini Hacker News

• Saat ini saya terjebak di lingkungan yang hanya bisa memakai CMake, GCC, dan Unix Make, jadi hampir mustahil mendapatkan informasi detail tentang kenapa build lambat. Build-nya juga berantakan, dengan langkah build rumit seperti menyalin file dari source ke folder build, memakai banyak bahasa (C, C++, Fortran, Python), langkah CMake kustom, dan lain-lain. Kalau alat ini bisa bekerja dengan baik bahkan di lingkungan sekacau ini, rasanya saya bisa belajar banyak sekali.

  • tsoding menulis library C single-header untuk build lintas platform di https://github.com/tsoding/nob.h, dan hanya butuh cc. Tahap build bisa dilihat memakai alat profiling GDB. Menurut saya ini ide yang keren. Mungkin tidak cocok untuk penulis artikel ini, tapi kalau harus menangani banyak bahasa, Nix adalah alat build yang sangat bagus.

  • Saya sendiri pernah membuat alat tracing/profiling waktu kompilasi sebagai plugin GCC. Kalau tertarik, bisa lihat di sini: https://github.com/royjacobson/externis

  • Saat mencoba mengurangi waktu kompilasi game engine saya, saya pernah memakai ukuran hasil kompilasi sebagai metrik pengganti. Karena waktu wall-clock terlalu tidak stabil, mengukur ukuran biner yang dihasilkan—yang sama untuk setiap build, bahkan di mesin berbeda—justru lebih mudah ditangani. Memang tidak cocok 100%, tapi secara praktik cukup membantu.

  • Saya mengalami masalah serupa. Saya kadang melihat CMake mengompilasi ulang file yang bahkan tidak saya ubah. Misalnya, hanya mengubah sedikit pada .cpp tanpa mengubah interface, tapi object yang sama sekali tidak terkait ikut dikompilasi ulang. Kadang saya bertanya-tanya apakah CMake membuat dependensi yang lebih kuat daripada file aslinya, sehingga waktu build jadi panjang tanpa alasan jelas.

• Saya ingin menyarankan kepada penulis blog agar menampilkan gif rekaman build aplikasi macOS di bagian atas halaman, tepat di bawah header. Menunjukkan hasilnya terlebih dahulu lalu menjelaskannya setelah itu akan lebih enak dilihat.

  • Saran yang bagus. Saya langsung memperbarui blog-nya.

• Saya sangat suka proyek ini. Saya pernah mencoba hal serupa pada 2018 dengan strace dan dtruss, serta https://buildinfer.loopperfect.com/, untuk hal-hal seperti membuat file BUCK secara otomatis. Visualisasinya memakai graphviz, perfetto.dev, dan lain-lain. Sayang saya tidak sempat mengemasnya jadi produk resmi, tetapi dalam pekerjaan konsultasi itu sangat membantu untuk diagnosis akar masalah dan migrasi ke BUCK/Bazel. Belakangan ini saya juga kembali memikirkannya untuk penggunaan yang lebih luas. Ada juga tantangan teknis yang memang mendasar pada pendekatan ini: log syscall bisa membengkak jadi puluhan sampai ratusan GB saat ditulis ke disk (misalnya llvm 50GB, dan dalam beberapa kasus lebih dari 100GB), semua tahap build seperti https dan IPC juga harus ditangani dengan baik (dulu ada klien yang setiap kali build menarik kode dari database Firebird lewat Perl), dan karena sifatnya analisis runtime, analisis harus diulang untuk setiap konfigurasi build.

  • Penasaran, bagaimana Anda melakukan logging syscall? Apakah memakai trik seperti LD_PRELOAD atau filtering dengan eBPF?

• Menurut saya ini keren. Banyak masalah yang terlewat hanya karena visualisasi seperti ini tidak ada. Sepuluh tahun lalu saat saya mengoptimalkan sistem build Mozilla, alat seperti ini pasti akan sangat membantu. Saya juga berharap artikelnya memberi lebih banyak detail tentang masalah nyata apa saja yang berhasil ditemukan.

  • (Penulis) Terima kasih. Panggilan saya dengan engineer Mozilla berakhir mendadak, jadi saya tidak sempat mendengar detail tentang masalah apa yang mereka temukan. Saya juga ingin memastikannya langsung.

• Di proyek C++ yang dikelola dengan CMake, saya pernah berhasil memakai ninjatracing dan -ftime-trace dari Clang untuk visualisasi performa build. Tambahan lagi, dengan ClangBuildAnalyzer, kita bisa menganalisis lebih rinci bagian mana di compiler yang menghabiskan waktu.

• Ini benar-benar keren. Apakah ada rencana untuk open source? Saya sedang membuat sesuatu yang mirip dan ingin berkolaborasi.

• Kalau memakai compiler Visual C++ di Windows, saya juga merekomendasikan vcperf. Ini sudah termasuk secara default di VS2022 atau bisa dibangun langsung dari GitHub. Saya pernah memakainya juga pada proyek yang dibuat dengan UBT atau CMake. Saya tidak ingat apakah alat ini bisa langsung menilai kualitas paralelisasi build, tetapi informasi frontend compiler-nya mudah dilihat. Khususnya, ini memudahkan menemukan file header yang sering di-include atau memang berat secara inheren.

  • Saya juga merekomendasikan Incredibuild. Bahkan versi gratisnya saja sudah cukup untuk memvisualisasikan build dan menemukan titik bottleneck.

• Ini pengamatan penting yang biasanya terlewat: logika build yang “baked in” (sudah dihitung sebelumnya) di dalam build system sebenarnya tidak melacak secara rinci perubahan apa yang benar-benar berdampak. Misalnya di ninja, sebagian logika build sudah dimasukkan sebelumnya sehingga cepat. Saya pernah membenchmark full build Xerces-C++ dengan ninja (dikonfigurasi lewat CMake) dan build2 (alat yang menangani konfigurasi dan pelacakan perubahan di dalam proses build). Hasilnya, ninja 3,23 detik dan build2 3,54 detik. Jika build diulang sambil mempertahankan sebagian file yang dibuat CMake, waktunya turun menjadi 3,28 detik. Sebagai referensi, tahap konfigurasi CMake saja memakan 4,83 detik. Jadi build penuh CMake+ninja sebagai satu kesatuan sebenarnya memakan sekitar 8 detik, dan itulah waktu yang biasanya benar-benar dialami saat memakai library ini.

  • kbuild membuat setiap target di Make bergantung pada file dummy agar perubahan opsi seperti CFLAGS bisa tercermin dengan benar. Ini dirancang supaya Make bisa dipakai seperti ninja, tanpa harus memasukkan seluruh graph build ke setiap proses Make. Saya penasaran bagaimana perbandingannya di praktik.

• Saya pernah mencoba pendekatan serupa dengan menjalankan Instruments selama proses build untuk mengetahui proses mana mengerjakan apa dan kapan. Kekurangannya, kalau build-nya lama Instruments jadi tersendat, dan juga tidak ada filtering process tree sehingga kurang nyaman. Meski begitu, ini sangat membantu saat memangkas besar-besaran waktu build kode iOS di Twitter. Belakangan, tracing “All Processes” di Instruments rusak, jadi metode ini sudah tidak bisa dipakai lagi.

• Terlihat sangat keren. Apakah ada versi macOS yang bisa langsung diuji sekarang? Saya ingin mencobanya untuk pekerjaan Rust atau C++/Swift juga.

  • Setelah bug fix, ada rencana membagikan versi macOS ke pengguna beta berikutnya. Kalau Anda mendaftar (di bagian bawah artikel) dan menyebut komentar ini, saya pasti akan memasukkan Anda ke grup beta.

  • Sepertinya belum ada rilis publik untuk OS mana pun, baru bisa mendaftar early access.