Saya membangun buildprof (GitHub), sebuah alat open source yang menunjukkan di mana waktu habis ketika Anda mengompilasi software di Linux. Ini video real-time profiling ripgrep build bersih: Lihat demo buildprof. Kadang-kadang, build lambat karena hanya saja ada banyak kode yang perlu dikompilasi.

Tapi lebih sering daripada tidak, ada masalah yang bisa diperbaiki: paralelisme yang buruk, kerja yang diulang, unduhan dependensi atau panggilan compiler/linker yang raksasa. buildprof membuat semua ini terlihat jelas, sehingga Anda bisa melihat yang layak ditelusuri dan dioptimalkan. Anda menjalankannya dengan menempatkan buildprof -- di depan setiap perintah build yang Anda gunakan: buildprof -- make -j16, buildprof -- cargo build, buildprof -- ninja -C out/target, buildprof -- just build, buildprof -- ./dev/custom-build-script.sh. buildprof merekam setiap proses yang perintah build Anda meluncurkan, termasuk subprocess-nya (dan subprocess-nya…), dan menempatkannya pada satu timeline. Waktu bergerak dari kiri ke kanan, lebar bar menunjukkan durasi, dan child process di bawah yang meluncurkannya.

Saya membuat buildprof karena tweet Jarred Sumner, arsitek utama runtime Bun, hidup sewa di kepalaku: Khususnya, klaim bahwa Bun build Rust baru >5× lebih cepat di Linux dibandingkan build Zig lama. Dari pengalaman saya, proyek Zig biasanya lebih cepat dikompilasi daripada proyek Rust kompleksitas yang sama. Intuisi ini cukup membuat saya merasa ada misteri yang harus diselesaikan.

Ini ditambah dengan detail penting namun mudah terlewat di tweet: build Zig menggunakan Full LTO, sedangkan build Rust menggunakan Thin LTO. Compiler umumnya optimize satuan kompilasi yang terpisah largely dalam isolasi. Link-time optimization (LTO) memungkinkan mereka optimize melintasi batas-batas tersebut.

Full LTO mengumpulkan those units menjadi satu optimisasi pekerjaan besar, sementara Thin LTO lebih banyak pemisahan sehingga sebagian besar pekerjaan bisa berjalan paralel. Dari pengalaman saya perbedaan ini dapat memiliki pengaruh raksasa pada waktu build. Tweet menyebutnya lewat, tapi saya bertanya-tanya seberapa banyak peningkatan headline itu sebenarnya menjelaskannya.

Saya mulai mencoba mereproduksi angka. Angka-angka tersebut direproduksi. Tapi sekarang? Saya mengunduh Bun 1.3.14 dan Bun 1.4.0 dan menulis skrip untuk mereplay CI build Linux x64-nya pada VM Linux 6 inti, 12 thread.

Skrip menyimpan langkah build dan ketergantungannya, menjalankan semuanya pada satu mesin. Waktu saya adalah dalam rentang yang sama dengan Jarred: Linux x64 build Zig era 30m06s, Rust era 5m37s. Replay CI single-machine 24m24s 5m40s.

Baik, jadi gap juga muncul di mesin saya. Tapi banyak yang berubah antara dua pengukuran selain bahasa; jadi apa yang sebenarnya bertanggung jawab? Apakah compiler Zig yang mengambil waktu extra semua itu? Atau mungkin itu Full LTO link. Atau mungkin ada sesuatu di build Bun yang belum saya pikirkan? Di sinilah otak profiling dan developer-tools saya ikut.

Biasanya, ketika saya mencoba memahami mengapa sesuatu lambat, saya ingin sebuah trace: apa yang terjadi, kapan terjadi, dan berapa lama yang ditempuh. Sangat keren jika kita punya trace untuk build-build ini, menempatkannya pada timeline dan melihat waktu sebenarnya mereka pergi. Tapi build melibatkan banyak alat yang berbeda, masing-masing punya pemikiran sendiri tentang yang terjadi.

Apa yang bisa saya catat agar bisa melihat melalui semua mereka? Builds adalah pohon proses. Ketika Anda mengetik cargo build atau zig build, terasa seperti Anda menjalankan satu program. Build system menentukan apa yang perlu dibangun, urutan antara bagian-bagian tersebut dan apa yang bisa berjalan paralel.

Tapi umumnya, ia tidak melakukan semua pekerjaan itu sendiri; ia meluncurkan compiler, code generators, archivers, linkers dan skripter arbitrer. Ini bisa meluncurkan program lebih lanjut yang meluncurkan beberapa lebih lanjut… Berbagai build system mendeskripsikan pekerjaan ini dengan cara yang berbeda. Cargo melihat crates, Ninja melihat build edges dan CMake menghasilkan instruksi untuk build system lain.

Dari sistem operasi.