Cerita di Balik Bun Install

• 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

[GN⁺]

Komentar Hacker News

• Saya mencoba memverifikasi klaim bahwa MacBook M4 Max yang saya pakai akan masuk 50 besar superkomputer TOP500 pada tahun 2009
  Untuk masuk TOP500 tahun 2009, dibutuhkan performa lebih dari 75 TFlop/s
  M4 Max memiliki 18.4 TFlop/s pada FP32, tetapi TOP500 menggunakan FP64 (LINPACK)
  Berdasarkan benchmark M2, FP64 berada di sekitar 1/4 dari FP32, jadi diperkirakan sekitar 9 TFlop/s
  Dengan angka segitu, tidak akan masuk TOP500 tahun 2009
  Lihat daftar TOP500 tahun 2009

  • Jika setiap koneksi menjalankan beberapa operasi I/O secara bersamaan, maka harus dikalikan dengan ribuan koneksi
    Saya pernah dengar server menghabiskan sekitar 95% waktunya menunggu I/O, tetapi itu sebenarnya berlaku untuk thread individual, bukan seluruh server
    Server nyata sering mencapai penggunaan CPU 70~80% (di atas itu, tail latency biasanya memburuk dengan cepat)
    Jika pada full load CPU hanya terpakai 5%, berarti ada kekurangan proses paralel atau masalah kekurangan memori
    Ini memang detail teknis kecil, tetapi kesalahan seperti ini bisa menurunkan kredibilitas tulisan (saya bilang ini sebagai penggemar Bun)

  • Kesimpulan itu terasa seperti halusinasi buatan LLM
    Bagian penutupnya terutama terasa seperti hasil keluaran LLM
    "Saya jadi paham bahwa package manager yang dibenchmark bukan salah, melainkan memang merupakan solusi yang sesuai untuk zamannya"
    "Yang ditekankan adalah bahwa pendekatan Bun bukanlah sesuatu yang revolusioner, melainkan hasil dari melihat dengan jernih apa yang membuat kecepatan menjadi lambat saat ini"
    "Pemasangan paket yang menjadi 25 kali lebih cepat bukanlah sihir, melainkan fenomena alami karena tool-nya dibuat sesuai dengan hardware modern"

• Meski topiknya rumit, penjelasannya sangat mudah dibaca dan sederhana, jadi saya sangat menyukainya
  Masih mengagumkan melihat ada orang-orang penuh semangat yang berani mendobrak status quo dan menantang masalah sulit
  Hardware komputer terus berkembang setiap bulan, tetapi software justru makin lambat, dan itu terasa tidak normal
  Saya berharap semua orang bisa makin baik dalam menulis kode yang efisien

  • Saya tidak tahu kalau bun ditulis dengan Zig
    Zig adalah bahasa yang sangat baru, jadi menarik melihatnya dipakai sungguh-sungguh di dunia nyata

• Saya baru pertama kali mencoba bun dan sangat terkesan
  Berkat server bawaan dan SQLite, saya cukup memasang bun saja sehingga pengembangan jadi jauh lebih nyaman
  Saya biasanya hanya memakai vanilla js dan memang tidak terlalu suka ekosistem node, jadi saya merasa seharusnya mencoba bun lebih awal

  • Saya sudah beberapa kali mencoba Bun, dan pengalaman memakainya sangat memuaskan
    Rasanya lebih baik daripada Node
    Tetapi saya selalu menabrak masalah yang krusial, dan akhirnya kembali ke Node
    Awalnya modul crypto tidak kompatibel dengan Nodejs (sekarang sudah diperbaiki), lalu berikutnya Playwright tidak berjalan di Bun

  • Sekarang Node juga mendukung server bawaan dan SQLite
    Kalau butuh fitur lebih banyak, Hono juga merupakan alternatif yang bagus

• Saya kurang paham bagian artikel yang menjelaskan bahwa hard link di Linux dan clonefile di MacOS itu setara
  Dalam kasus hard link, bukankah kalau satu salinan diubah maka file di semua proyek ikut berubah tanpa diduga?

• Saya kagum karena meski penjelasannya cukup rumit secara teknis, tulisannya tetap sangat mudah dibaca dan menyenangkan

  • Lydia sangat mahir menyampaikan konsep rumit dengan cara yang mudah dipahami
    Saya sudah melihat sebagian besar karya dan videonya, dan terasa sekali bahwa semuanya dipersiapkan dengan mendalam
    Kalau ada waktu, saya sangat merekomendasikan artikel dan konten YouTube-nya
    Belakangan ini aktivitasnya mungkin berkurang karena pekerjaan utamanya saat ini

• Di bagian Binary Manifest Caching, sepertinya waktu benchmark untuk "npm (cached)" hilang
  Yang ada hanya bun, bun (cached), dan npm, dan statistik ringkasannya juga tampaknya tidak terlalu cocok

• Saya sangat suka gaya penulisan postingan ini
  Tulisan ini rasanya bisa diposisikan ulang sebagai contoh yang sangat baik untuk menjelaskan pentingnya io_uring
  Saya penasaran apakah update io terbaru di Zig v0.15 bisa memberi keuntungan tambahan pada performa Bun

• Saya sudah menantikan bun selama lebih dari 1 tahun
  Saya kira 2025 akan menjadi tahun awal bun benar-benar populer, tetapi ternyata belum juga sepopuler itu
  Di 100 ribu repositori teratas GitHub, untuk repositori baru pada 2025, npm dipakai 35 kali lebih banyak dan pnpm 11 kali lebih banyak
  Deno juga ternyata tidak sepopuler yang saya kira
  Saya penasaran apa alasannya
  Apakah karena runtime lebih sulit mengejar kompatibilitas dibanding package manager?
  Saya ingin mendengar pendapat orang-orang yang pernah mencoba bun tetapi tidak jadi mengadopsinya
  Statistik terkait
  Komentar HN terkait

  • Saya ingin menyukai Bun dan Deno, jadi saya sudah beberapa kali mencobanya, tetapi selalu bertemu cacat fatal hingga akhirnya tidak bisa lanjut memakainya
    Masalah terbesar yang baru-baru ini saya alami di Bun adalah stream yang tertutup terlalu cepat
    Tautan issue terkait
    Di Deno, saya mengalami masalah memory leak
    Tautan issue terkait
    Pada akhirnya saya merasa ekosistem Node kemungkinan akan lebih dulu menyerap keunggulan-keunggulan Bun/Deno

  • Bun adalah pendatang baru yang didanai venture capital dan bersaing dengan produk open source arus utama yang sudah terbukti, yaitu Node
    Ada insentif lock-in, dan pada akhirnya tidak terlalu berbeda secara mendasar dari Node
    Kelebihan strategisnya tidak terasa jelas, dan Bun tidak menawarkan sesuatu yang benar-benar baru yang tidak bisa dilakukan Node
    Saya belum pernah melihat penggunaan yang benar-benar serius, hanya penggunaan kasual

  • Melihat issue tracker-nya, tampaknya crash cukup sering terjadi, mungkin karena bahasa Zig sendiri sangat tidak aman
    Saya akan tetap bertahan di Node

  • Saya juga penasaran dengan pendapat orang lain
    Menurut saya Node sebagai proyek sudah matang, demokratis, dan sangat terasa digerakkan komunitas
    Itu juga karena proyek ini berhasil melewati perpecahan fork io.js dengan baik
    Sebaliknya, bun maupun deno sama-sama proyek yang didukung VC, jadi tidak terasa sebagai komunitas yang demokratis dan digerakkan bersama

  • Saya penggemar berat Bun
    Saya memakai Bun di semua proyek yang memungkinkan, dan juga memakai Bun/TS untuk berbagai skrip one-off
    Hanya saja ada beberapa issue kecil yang tetap membuat saya khawatir, jadi saya masih ragu untuk deployment produksi
    Misalnya, ketika saya menjalankan web server Express sederhana di Docker, proses dengan bun bisa macet
    Kalau diganti ke node saja, semuanya berjalan normal
    Setahun lalu juga ada masalah server mati karena memory leak pada kombinasi Bun + Prisma (kemungkinan sekarang sudah diperbaiki)
    Meski begitu, saya sangat menyukai Bun sehingga secara keseluruhan waktu pengembangan tetap berkurang walaupun harus menerima kekurangan ini
    Kenyamanan dari transpile, modul, workspace, dan sebagainya benar-benar besar
    Saya juga sangat paham kenapa Bun belum sepopuler npm

• Sangat menyenangkan membaca tulisan ini
  Ini contoh yang bagus tentang betapa pentingnya prinsip-prinsip ilmu komputer dalam pengembangan software nyata
  Big O, lokalitas waktu/ruang, kompleksitas algoritma, user/kernel space, file system, copy-on-write, dan sebagainya
  Dalam pengembangan package tingkat rendah seperti ini, semua konsep yang dipelajari di program CS benar-benar dipakai dalam praktik

  • Sebenarnya ini lebih dekat ke software engineering (SE) daripada computer science (CS)
    CS meneliti komputasi dan teori (bahasa pemrograman, algoritma, kriptografi, machine learning, dan sebagainya)
    Sedangkan SE menerapkan prinsip-prinsip rekayasa untuk membangun software yang skalabel dan andal

• Saya kurang paham kenapa lebih menguntungkan membaca seluruh berkas terkompresi dulu baru mengekstraknya
  Saya menduga mulai dekompresi sebelum unduhan selesai justru lebih menguntungkan daripada kerugiannya berupa bertambahnya jumlah penyalinan ulang memori