- Instalasi paket Bun berjalan sangat cepat dibandingkan package manager yang sudah ada
- Kunci dari instalasi yang cepat terletak pada pendekatan dari sudut pandang pemrograman sistem dan meminimalkan system call
- Peningkatan performa dicapai melalui penerapan strategi yang detail seperti coding native berbasis bahasa Zig, penggunaan cache biner, dan optimasi per OS
- Bahkan dalam proses ekstraksi tarball dan penyalinan file, diperkenalkan metode berperforma tinggi yang memanfaatkan karakteristik hardware
- Optimasi struktur data seperti grafik dependensi dan lockfile meningkatkan efisiensi cache CPU dan akses memori
Mengapa Bun Install cepat
bun install dari Bun rata-rata memberikan performa instalasi paket 7x lebih cepat daripada npm, 4x lebih cepat daripada pnpm, dan 17x lebih cepat daripada yarn- Ini bukan sekadar benchmark, melainkan karena masalah instalasi paket didekati dari sudut pandang pemrograman sistem, bukan JavaScript
- Bun secara agresif menerapkan optimasi performa di berbagai lapisan, termasuk minimisasi system call, caching biner manifest, optimasi ekstraksi tarball, dan penyalinan file native per OS
Keterbatasan Node.js dan arsitektur package manager
- Sejak Node.js dirilis pada 2009, model asynchronous IO berbasis event loop dan thread pool ikut menyebar ke package manager
- Saat itu, strategi asynchronous IO dan frekuensi system call yang tinggi masuk akal karena keterbatasan hardware seperti disk lambat dan jaringan lambat
- Namun pada sistem modern, NVMe SSD, jaringan cepat, dan CPU berkinerja tinggi sudah umum, dan bottleneck yang sebenarnya bukan lagi IO melainkan overhead system call
Biaya system call dan mode switch
- Ketika program meminta operasi seperti membaca file, program harus beralih dari user mode ke kernel mode, dan proses ini menghabiskan siklus CPU yang mahal (1000~1500 cycles)
- Instalasi paket pada dasarnya memerlukan puluhan ribu hingga ratusan ribu system call, sehingga biaya perpindahan kerja itu sendiri dapat menghabiskan beberapa detik waktu CPU
- Sebagai contoh, saat menginstal React dan dependensinya, npm menggunakan sekitar 1 juta system call, yarn 4 juta, pnpm 500 ribu, dan bun 160 ribu
Perbedaan pendekatan antara package manager lama dan Bun
- npm, pnpm, dan yarn semuanya berbasis Node.js, sehingga JavaScript harus dijalankan melalui beberapa lapisan abstraksi (libuv, event loop, thread pool, perantara system call)
- Di sini, konversi argumen, antrean worker pool, percabangan pekerjaan event loop, dan system call futex (sinkronisasi lock) menumpuk, sehingga pengelolaan system call justru menjadi lebih lambat daripada IO itu sendiri
- Package manager yang dibuat dengan Node.js sulit mencapai performa yang benar-benar mendekati native karena keterbatasan struktural ini
Bun: mesin instalasi native yang diimplementasikan dengan Zig
- Bun langsung memanggil system call dengan bahasa Zig, sehingga seluruh lapisan abstraksi dan JavaScript engine dapat dilewati
- Misalnya, pembacaan file mengeksekusi system call
openat() langsung dari kode Zig lalu segera mengembalikan data
- Karena itu, proses membaca puluhan ribu file dapat berjalan sangat cepat tanpa thread pool, event loop, atau proses konversi data tambahan
- Dalam benchmark, Bun dapat membaca 146.057
package.json per detik, sementara Node.js berada di kisaran 60 ribu dan lebih dari 2x lebih lambat
Optimasi manajemen dependensi dan DNS
- Saat
bun install dijalankan, Bun memicu analisis dependensi sekaligus DNS prefetch secara asynchronous
- Misalnya di macOS, Bun menggunakan API async DNS tidak resmi milik Apple (
getaddrinfo_async_start()), sehingga pekerjaan jaringan dapat diproses bersamaan tanpa memblokir thread
- Package manager lama menggunakan thread pool berbasis libuv, sehingga pada praktiknya kode blocking tetap dijalankan secara internal dan membuang sumber daya
Caching biner untuk manifest paket
- npm dan lainnya menyimpan manifest sebagai JSON, tetapi Bun mem-parsing sekali lalu menyimpan hasilnya dalam bentuk biner (file
.npm)
- Dengan ini, duplikasi string dan overhead parsing diminimalkan, dan di memori nilai dapat diakses langsung hanya melalui perhitungan offset (tanpa membuat objek baru, parsing ulang, atau garbage collection)
- Dengan header ETag dan If-None-Match, hanya perubahan yang diperiksa sehingga validasi kebaruan bisa dilakukan tanpa parsing data yang tidak perlu
- Dalam benchmark, instalasi dari cache Bun bahkan lebih cepat daripada fresh install npm
Performa pemrosesan Tarball (file terkompresi)
- Package manager umum menerima tarball sebagai stream, sehingga ketika memori buffer kurang, realokasi, penyalinan, dan resize terjadi berulang kali
- Bun menerima seluruh tarball terlebih dahulu lalu mengekstraknya, dan mengetahui ukuran uncompress lebih dulu lewat 4 byte terakhir gzip sehingga memori hanya dialokasikan sekali
- Dengan memanfaatkan
libdeflate dan sejenisnya, dekompresi menjadi lebih cepat, dan seluruh penyalinan ganda serta resize ukuran yang tidak perlu dapat dihilangkan
Grafik dependensi & optimasi struktur data
- Package manager lama membuat tree dependensi berbasis object/pointer JavaScript, yang menyebabkan penyebaran memori acak dan sering memicu cache miss CPU (masalah pointer chasing)
- Bun menerapkan pola Structure of Arrays (SoA), sehingga semua paket, string, dan dependensi disimpan dalam blok memori kontinu yang besar
- Dengan akses berbasis offset/panjang, CPU dapat membaca banyak paket sekaligus per cache line (struktur yang ramah cache)
- Lockfile juga disimpan sesuai pola SoA, bukan JSON/YAML, agar deduplikasi string dan akses memori sekuensial lebih mudah
- Format biner lockfile (
bun.lockb) juga sempat diperkenalkan secara eksperimental, tetapi kemudian dialihkan ke format plain yang lebih mudah dibaca karena kolaborasi Git menurun
Optimasi penyalinan file per OS
macOS
- Menggunakan clonefile: menggandakan direktori utuh dengan satu system call menggunakan metode Copy-On-Write
- Meminimalkan penggunaan ruang disk yang duplikat sekaligus memaksimalkan kecepatan instalasi
- Jika
clonefile gagal, fallback dilakukan bertahap ke cloning per-directory lalu copyfile
Linux
- Mencoba hard link terlebih dahulu: tidak membuat file baru, hanya membuat referensi baru ke file yang sudah ada (tanpa perpindahan data di disk)
- Jika hard link tidak memungkinkan, pada Btrfs/XFS digunakan
ioctl_ficlone untuk menerapkan Copy-On-Write
- Setelah itu fallback berurutan ke
copy_file_range, sendfile, lalu terakhir metode copyfile biasa
Ringkasan
- Bun melampaui batas performa tradisional package manager melalui minimisasi system call, struktur biner, optimasi OS, dan perbaikan struktur data
- Hasilnya, selain instalasi yang sangat cepat, efisiensi memori dan CPU juga ikut meningkat
- Dibandingkan manager berbasis Node.js yang ada, Bun dapat diterapkan ke proyek tanpa harus mengganti runtime secara terpisah (kompatibilitas tetap terjaga)
- Dalam codebase besar di dunia nyata, pengalaman yang diberikan adalah memangkas proses instalasi yang tadinya memakan beberapa menit menjadi hanya beberapa milidetik hingga beberapa detik
- Ini menjadi contoh unggulan optimasi yang disesuaikan dengan level sistem, hardware, dan OS, sehingga sangat bernilai untuk diteliti dan dijadikan referensi
Belum ada komentar.