Bun Install'ın Perde Arkası

• Bun'un paket kurulumu, mevcut paket yöneticilerine kıyasla çok daha hızlı çalışır
• Bu hızlı kurulumun temelinde sistem programlama bakış açısı ve sistem çağrılarını en aza indirme yaklaşımı yer alır
• Zig diliyle yerel kodlama, ikili önbellek kullanımı ve işletim sistemine özel optimizasyonlar gibi ayrıntılı stratejilerle performans artışı sağlanır
• tarball açma ve dosya kopyalama sürecinde de donanım özelliklerinden yararlanan yüksek performanslı yöntemler kullanılır
• Bağımlılık grafiği ve lockfile gibi alanlarda veri yapısı optimizasyonu ile CPU önbellek verimliliği ve bellek erişilebilirliği artırılır

---

Bun Install neden hızlı?

• Bun'un bun install komutu ortalama olarak npm'den 7 kat, pnpm'den 4 kat, yarn'dan 17 kat daha hızlı paket kurulumu sunar
• Bunun nedeni yalnızca bir benchmark sonucu değil, paket kurma probleminin JavaScript yerine sistem programlama perspektifiyle ele alınmış olmasıdır
• Sistem çağrılarını azaltma, manifestleri ikili olarak önbellekleme, tarball çıkarma optimizasyonu ve işletim sisteminin yerel dosya kopyalama yetenekleri gibi birçok katmanda agresif performans optimizasyonları uygulanır

Node.js ve paket yöneticisi mimarisinin sınırları

• Node.js'in 2009'da yayınlanmasının ardından, event loop ve thread pool tabanlı asenkron IO modeli paket yöneticilerine de yayıldı
• O dönemde donanım kısıtları nedeniyle (yavaş diskler, yavaş ağlar) asenkron IO ve yüksek sistem çağrısı sıklığı mantıklıydı
• Ancak modern sistemlerde NVMe SSD, hızlı ağ ve yüksek performanslı CPU yaygın hale geldi ve asıl darboğaz artık IO değil, sistem çağrısı ek yükü oldu

Sistem çağrıları ve kip geçişinin maliyeti

• Bir program dosya okuma gibi bir işlem istediğinde, user mode'dan kernel mode'a geçmesi gerekir ve bu süreç pahalı CPU döngüleri (1000~1500 cycles) tüketir
• Paket kurulumu temelde on binlerce ila yüz binlerce sistem çağrısı gerektirdiğinden, yalnızca iş geçiş maliyeti bile saniyeler düzeyinde CPU zamanı harcatabilir
• Örneğin React ve bağımlılıklarını kurarken npm yaklaşık 1 milyon, yarn 4 milyon, pnpm 500 bin, bun ise 160 bin sistem çağrısı kullanır

Mevcut paket yöneticileri ile Bun'un yaklaşımı arasındaki fark

• npm, pnpm ve yarn'ın tamamı Node.js tabanlıdır; yani JavaScript'in birden fazla soyut katman üzerinden çalıştırılması gerekir (libuv, event loop, thread pool, sistem çağrısı aracılığı)
• Bu sırada argüman dönüşümü, worker pool kuyruğu, event loop iş dallanması ve futex (kilit senkronizasyonu) sistem çağrıları birikerek IO'dan çok sistem çağrısı yönetimini yavaşlatır
• Node.js ile yazılmış paket yöneticileri, bu yapısal sınırlamalar nedeniyle gerçek anlamda yerel performansa yaklaşmakta zorlanır

Bun: Zig ile yazılmış yerel kurulum motoru

• Bun, sistem çağrılarını doğrudan yapmak için Zig dilini kullanır ve JavaScript motoru/soyutlama katmanlarını tamamen atlar
• Örneğin dosya okuma, Zig kodunda doğrudan openat() sistem çağrısını çalıştırıp veriyi hemen döndürür
• Böylece on binlerce dosyanın okunması, ek bir thread pool, event loop veya veri dönüştürme süreci olmadan son derece hızlı gerçekleşir
• Benchmark sonuçlarına göre Bun saniyede 146.057 adet package.json okuyabilirken, Node.js 60 bin civarında kalır ve 2 kattan fazla daha yavaştır

Bağımlılık yönetimi ve DNS optimizasyonu

• Bun, bun install çalışırken bağımlılık analizini yaparken aynı anda DNS prefetch işlemini de asenkron olarak tetikler
• Örneğin macOS'ta Apple'ın resmî olmayan async DNS API'si olan getaddrinfo_async_start() kullanılır ve thread bloklamadan ağ işlemlerinin eşzamanlı yürütülmesi sağlanır
• Mevcut paket yöneticileri ise libuv thread pool tabanlıdır; yani pratikte içeride bloklayan kod çalıştırarak kaynak israfına yol açar

Paket manifestlerinin ikili önbelleğe alınması

• npm gibi araçlar manifestleri JSON olarak önbelleğe alırken, Bun bir kez parse ettikten sonra sonucu ikili (.npm dosyası) biçimine dönüştürerek saklar
• Böylece string tekrarları ve parse ek yükü azaltılır; gerçek bellekte ise yalnızca offset hesaplamasıyla değerlere doğrudan erişilebilir (yeni nesne oluşturma, parse veya garbage collection gerekmez)
• ETag ve If-None-Match başlıklarıyla yalnızca değişiklikler kontrol edilir; gereksiz veri parse etmeden güncellik doğrulanabilir
• Benchmark'ta Bun'un önbellekten yaptığı kurulum, npm'in fresh install işleminden bile daha hızlıdır

Tarball (sıkıştırılmış dosya) işleme performansı

• Tipik paket yöneticileri tarball'ı akış olarak alır ve tampon bellek yetmediğinde yeniden ayırma, kopyalama ve yeniden boyutlandırma işlemleri peş peşe yaşanır
• Bun ise tarball'ın tamamını aldıktan sonra açar; gzip'in son 4 baytından sıkıştırılmamış boyutu önceden öğrenip yalnızca bir kez bellek ayırır
• libdeflate gibi araçlarla hızlı açma sağlanır; gereksiz tekrar kopyalama ve boyut değiştirme işlemleri tamamen ortadan kaldırılır

Bağımlılık grafiği ve veri yapısı optimizasyonu

• Mevcut paket yöneticileri JavaScript nesneleri/işaretçileri tabanlı bağımlılık ağaçları oluşturur; bu da belleğin rastgele dağılmasına ve sık CPU cache miss oluşmasına yol açar (pointer chasing sorunu)
• Bun, Structure of Arrays (SoA) desenini uygulayarak tüm paketleri, string'leri ve bağımlılıkları büyük ve ardışık bellek bloklarında saklar
  • Offset/uzunluk tabanlı erişim sayesinde CPU, birden fazla paketi tek seferde cache line düzeyinde okuyabilir (cache dostu yapı)
  • lockfile da JSON/YAML yerine SoA desenine uygun biçimde, string tekrarları kaldırılmış ve sıralı bellek erişimi kolay olacak şekilde tutulur
• lockfile için ikili biçim (bun.lockb) deneysel olarak sunuldu ancak Git ile ortak çalışma deneyimini kötüleştirdiği için daha okunabilir düz metin biçimine geçildi

İşletim sistemine göre dosya kopyalama optimizasyonu

macOS

• clonefile kullanımı: tüm dizin, tek bir sistem çağrısıyla Copy-On-Write yöntemiyle çoğaltılır
• Disk alanı tekrar kullanımını en aza indirir ve kurulum hızını en üst düzeye çıkarır
• clonefile başarısız olursa yedek olarak dizin bazlı kopyalama, ardından copyfile kullanılır

Linux

• Önce hardlink denenir: yeni dosya oluşturmak yerine mevcut dosya için yeni bir referans oluşturulur (disk verisi taşınmaz)
• Hardlink mümkün değilse Btrfs/XFS üzerinde ioctl_ficlone ile Copy-On-Write uygulanır
• Ardından sırasıyla copy_file_range, sendfile ve son olarak normal copyfile yöntemine geri düşülür

Genel değerlendirme

• Bun, sistem çağrılarını azaltma, ikili yapılar, işletim sistemi optimizasyonları ve veri yapısı iyileştirmeleri sayesinde paket yöneticilerinin geleneksel performans sınırlarını aşmıştır
• Bunun sonucunda yalnızca son derece hızlı kurulum değil, aynı zamanda daha iyi bellek ve CPU verimliliği de sağlanır
• Mevcut Node.js tabanlı yöneticilere kıyasla, ayrı bir runtime değişikliği gerektirmeden projelerde uygulanabilir (uyumluluk korunur)
• Gerçek büyük kod tabanlarında dakikalar süren kurulum işlemlerini milisaniyeler ila saniyeler seviyesine indirme deneyimi sunar
• Sistem, donanım ve işletim sistemi düzeyine göre uyarlanmış optimizasyonların güçlü bir örneği olarak incelenmeye ve referans alınmaya değerdir