Rust Compiler Makin Cepat 4,57 Persen dalam Dua Bulan, Ini PR-nya

Kompiletor Rust turun sekitar 4,57 persen rata-rata waktu jalan dalam dua bulan, menurut pengukuran periode 29 Juli sampai 28 September 2026 yang dilaporkan Nick Nethercote pada posting 30 September 2026. Dari 629 sampel benchmark, 555 membaik dan hanya 74 yang memburuk, dan sebagian mencatat penurunan dua digit. Kontribusi terbesarnya datang dari PGO untuk Clippy dengan keuntungan terbaik 18 persen, upgrade ke LLVM 23 yang memberi 1,2 persen rata-rata, serta perbaikan algoritma traversal dataflow yang memangkas sekitar 30 persen waktu build satu crate.

TL;DR

• Rata-rata penurunan wall time 4,57 persen untuk periode 29 Juli sampai 28 September 2026, diukur pada 629 sampel dengan hasil 555 membaik dan 74 memburuk.
• PGO untuk Clippy memberi perbaikan waktu jalan di sebagian besar benchmark Clippy, dengan kasus terbaik 18 persen, sementara upgrade ke LLVM 23 menyumbang 1,2 persen rata-rata lintas benchmark.
• Perubahan algoritma traversal CFG di analisis dataflow memangkas panggilan apply_effects_in_block dari 1,5 juta menjadi 90 ribu pada satu fungsi raksasa di cranelift-codegen, hasilnya sekitar 30 persen untuk build pengecekan crate itu.
• Dua fitur baru yang secara desain lebih lambat kini aktif di Nightly, borrow checker Polonius Alpha dan trait solver baru, dan keduanya memerlukan pekerjaan khusus supaya regresinya tertutup.
• Satu perbaikan berasal dari hal paling membosankan yang ada: menaikkan ukuran stack default kompiletor sehingga mekanisme perpanjangan stack manual bisa dihapus.

Apa yang berubah di kompiletor Rust dalam dua bulan terakhir?

Lapisan perbaikan datang dari beberapa arah sekaligus, dan laporan itu merinci pemicunya satu per satu. Yang paling besar efek satu PR adalah mengaktifkan profile-guided optimization untuk Clippy lewat PR 159642 yang dikerjakan Jakub Beranek: waktu jalan membaik di sebagian besar benchmark Clippy, dengan kasus terbaik 18 persen. Selanjutnya upgrade LLVM ke versi 23 lewat PR 158734 milik Nikita Popov, yang menurunkan rata-rata waktu jalan 1,2 persen di seluruh benchmark. Nethercote mencatat angka itu terlihat kecil, tetapi justru impresif untuk satu PR, karena upgrade LLVM biasanya juga membawa risiko regresi.

Di luar dua perubahan besar itu, mayoritas perbaikan berupa pemangkasan pekerjaan yang tidak perlu di jalur panas. Menghindari alokasi di proses obligasi trait memberi penurunan sampai 2 persen di beberapa benchmark, mengganti dispatch dinamis dengan dispatch statis di kode pemilih solver lama dan baru memberi penurunan di bawah 1 persen, dan perubahan struktur data serta tweak inlining menyumbang potongan kecil di banyak benchmark sekaligus. Tidak ada satu PR ajaib di sini, yang ada adalah ratusan pekerjaan kecil yang diukur dengan alat yang sama.

Kenapa satu fungsi bisa memperlambat seluruh build?

Karena algoritma traversal yang salah pilih jadi mahal hanya pada kode yang ekstrem. Di PR 160193, Nethercote mengganti algoritma traversal CFG yang dipakai analisis dataflow di kompiletor. Analisis jenis ini mengulang sampai mencapai titik tetap, dan urutan traversal menentukan seberapa cepat titik tetap itu tercapai. Untuk sebagian besar kode, algoritma baru tidak mengubah apa pun. Masalahnya muncul pada crate cranelift-codegen yang punya satu fungsi raksasa dengan lebih dari 18 ribu basic block. Algoritma lama membutuhkan 1,5 juta panggilan ke apply_effects_in_block untuk mencapai titik tetap pada analisis EverInitializedPlaces yang dipakai borrow checker, sedangkan algoritma baru cukup 90 ribu panggilan. Hasilnya sekitar 30 persen penurunan waktu jalan untuk build pengecekan crate tersebut. Lanjutannya di PR 160033: analisis yang sama dibuat lebih hemat dengan tidak melacak data yang tidak perlu untuk proyeksi, dan itu menurunkan jumlah instruksi pada benchmark match-stress sebesar 17 persen.

Pelajaran praktisnya berlaku di luar Rust. Kalau sebuah pass analitis berjalan sampai konvergensi, biaya totalnya ditentukan oleh urutan kunjungan, bukan hanya oleh biaya per langkah. Kode yang dipecah ke banyak fungsi kecil tidak akan memperlihatkan efeknya, sehingga benchmark yang menyertakan satu fungsi ekstrem adalah bagian penting dari alat ukur, bukan keanehan yang perlu dibuang.

Dua fitur baru yang justru lebih lambat, kenapa tetap jalan?

Karena keduanya menerima program yang benar dan tidak bisa dikerjakan fitur lama. Borrow checker baru, Polonius Alpha, sudah diaktifkan di Nightly dan lebih presisi dari borrow checker yang sekarang dipakai, sehingga ia menerima sebagian program valid yang ditolak borrow checker lama. Harganya adalah kerja tambahan yang cukup untuk terlihat di waktu kompilasi pada sebagian kecil kasus, termasuk crate populer serde. Trait solver baru punya cerita yang sama: lebih lambat di minority kasus, dan timnya menulis catatan panjang soal pekerjaan penutupan celah itu.

Yang membuat dua regresi ini tidak merusak hasil keseluruhan adalah volume perbaikan lain. Nethercote mencatat bahwa deretan hijau di grafik justru menunjukkan regresi dari kedua fitur baru itu tertimbun oleh banyak perbaikan lain. Untuk pekerjaan penambalannya, liveness computation dibuat malas dan itu menurunkan jumlah instruksi serde 3 sampai 5 persen, sementara penyesuaian struktur data dan inlining memberi potongan di bawah 1 persen di banyak benchmark. Ada juga catatan menarik soal mengapa upaya pertama bisa gagal: ide mengganti dispatch dinamis dengan dispatch statis sempat dicoba lebih awal di PR 155714 lalu memicu regresi di beberapa benchmark, kemungkinan karena penempatan atribut inline yang sedikit berbeda, dan versi akhirnya baru mulus.

Berapa banyak perbaikan yang datang dari hal sepele?

Cukup untuk masuk laporan resmi. PR 160535 dari Chris Denton menaikkan ukuran stack default yang dipakai kompiletor, dan efek berantainya memungkinkan penghapusan ensure_sufficient_stack, mekanisme perpanjangan stack manual yang ditaburkan di tempat-tempat dengan rekursi dalam. Topik ini memicu diskusi panjang karena memutuskan cara terbaik menangani kehabisan stack memang tidak mudah, tetapi hasilnya adalah kode yang lebih sedikit dan jalur yang lebih sederhana. Di sisi lain, pekerjaan besar juga datang dari alat ukur: seluruh angka di laporan ini bersumber dari dashboard benchmark performa resmi proyek Rust, tempat tiap PR diukur ulang, sehingga klaim kecepatan bukan perasaan melainkan selisih yang bisa dilihat orang lain.

Perubahan	Penanggung jawab	efek terukur
PGO untuk Clippy	Jakub Beranek, PR 159642	Perbaikan waktu jalan di sebagian besar benchmark Clippy, kasus terbaik 18 persen
Upgrade ke LLVM 23	Nikita Popov, PR 158734	Rata-rata penurunan waktu jalan 1,2 persen lintas benchmark
Algoritma traversal CFG baru	Nick Nethercote, PR 160193	Sekitar 30 persen untuk build pengecekan cranelift-codegen
EverInitializedPlaces lebih hemat	Nick Nethercote, PR 160033	Penurunan jumlah instruksi 17 persen pada match-stress
Liveness computation dibuat malas	Jack Huey, PR 161938	Penurunan jumlah instruksi serde 3 sampai 5 persen

Apakah angka 4,57 persen itu terasa di proyek sehari-hari?

Untuk kebanyakan orang, iya, tapi jangan dibaca sebagai janji. Angka 4,57 persen adalah rata-rata di kumpulan benchmark resmi, dan distribusi yang sebenarnya lebih penting: dari 629 pengukuran, 555 membaik dan 74 memburuk, artinya ada proyek yang tidak ikut cepat, dan crate yang sangat bergantung pada trait solving bisa berada di pihak yang belakangan. Kalau build timmu didominasi satu crate dengan fungsi raksasa atau banyak analisis dataflow, efeknya bisa lebih besar dari rata-rata. Kalau didominasi linking atau dependency graph yang luas, hasilnya mendekati nol. Cara paling jujur menilai adalah mengukur dua kali pada kode sendiri, dengan toolchain berbeda versi, sebelum menjadikan angka ini dasar keputusan apa pun.

Satu catatan penutup yang layak dikutip karena jarang diucapkan: Nethercote menulis bahwa ia tetap menulis seluruh kode dan teksnya sendiri karena proyek punya kebijakan soal itu, tetapi ia memakai bantuan analisis LLM di beberapa PR yang dibahas di laporan tersebut. Model, menurutnya, sudah sangat bagus untuk jenis analisis tertentu. Itu posisi yang lebih konkret daripada debat generik soal AI dan developer, dan cocok dibaca sebagai pola kerja: manusia tetap penulis perubahan, mesin dipakai untuk membaca profil dan menyempitkan hipotesis.

Apa yang bisa ditiru tim yang merawat basis kode sendiri?

Tiga hal dari laporan ini bisa dibawa ke proyek biasa tanpa perlu jadi kontributor kompiletor. Yang pertama adalah memiliki benchmark yang tetap jalan saat fitur baru aktif, karena dua fitur yang secara desain lebih lambat bisa tetap diluncurkan tanpa membuat pengalaman build memburuk justru karena alat ukurnya ada dan perbaikannya dikejar sampai selisihnya tertutup. Yang kedua adalah mengukur hal yang membosankan: banyak perbaikan di daftar ini berupa penghapusan alokasi, penggantian bentuk dispatch, atau penyesuaian ukuran stack, dan masing-masing hanya berarti kalau seseorang mengukurnya lebih dulu. Yang ketiga adalah memisahkan klaim dari opini, karena laporan ini menuliskan angka per PR beserta sumbernya sehingga orang lain bisa tidak setuju dengan datanya, bukan dengankesan penulisnya.

Untuk tim yang kompiletornya bukan Rust, polanya tetap sama. Perubahan performa yang bertahan adalah yang bisa diulang oleh orang lain dengan alat yang sama, dan itu berarti satu dashboard publik lebih berguna daripada sepuluh anekdot di tiket. Kalau proyekmu belum punya baseline seperti itu, pekerjaan pertamanya bukan mengoptimalkan kodenya, melainkan membuat pengukuran yang bisa dijalankan ulang oleh orang kedua di tim.

FAQ

Ke mana saya melihat angka benchmark aslinya?

Di dashboard performa resmi Rust di perf.rust-lang.org, tempat hasil pengukuran per rentang waktu disimpan dan bisa dibandingkan per PR. Laporan September 2026 ini mengacu ke pengukuran periode 29 Juli sampai 28 September 2026.

Apakah Clippy ikut lebih cepat untuk semua proyek?

Tidak semua, tapi arahnya konsisten. Profil-guided optimization untuk Clippy memperbaiki waktu jalan di sebagian besar benchmark Clippy, dengan kasus terbaik 18 persen, sehingga proyek yang banyak menjalankan pemeriksaan lint paling merasakan manfaatnya.

Bisakah Polonius dipakai di proyek produksi sekarang?

Fitur itu aktif di Nightly, bukan di jalur stabil, dan artikel ini tidak menemukan pernyataan bahwa ia sudah siap untuk rilis stabil. Jadi untuk toolchain produksi, jawabannya belum, sementara untuk eksperimen dan penilaian presisi, ya.

Berapa lama siklus perbaikan seperti ini?

Laporan ini menutup dua bulan, dan Nethercote menyebut tulisan sebelumnya terbit dua bulan sebelumnya, sehingga polanya kira-kira satu laporan per dua bulan dengan metode pengukuran yang sama.