Bun Install की अंदरूनी कहानी

 (bun.com)
2 पॉइंट द्वारा GN⁺ 2025-09-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Bun का पैकेज इंस्टॉलेशन मौजूदा पैकेज मैनेजरों की तुलना में बहुत तेज़ गति से काम करता है
  • तेज़ इंस्टॉलेशन की कुंजी system programming दृष्टिकोण और system calls को न्यूनतम करना है
  • Zig भाषा आधारित native coding, binary cache का उपयोग, और OS-विशिष्ट optimization जैसी सूक्ष्म रणनीतियों के माध्यम से प्रदर्शन बेहतर किया गया है
  • tarball extraction और file copy प्रक्रिया में भी hardware की विशेषताओं का उपयोग करने वाले high-performance तरीकों को अपनाया गया है
  • dependency graph और lockfile जैसे क्षेत्रों में data structure optimization के जरिए CPU cache efficiency और memory accessibility बढ़ाई गई है

Bun Install तेज़ क्यों है

  • Bun का bun install औसतन npm से 7 गुना, pnpm से 4 गुना, और yarn से 17 गुना तेज़ पैकेज इंस्टॉलेशन प्रदर्शन देता है
  • यह सिर्फ़ benchmark का परिणाम नहीं है, बल्कि इसलिए संभव है क्योंकि पैकेज इंस्टॉलेशन की समस्या को JavaScript नहीं बल्कि system programming के नज़रिए से देखा गया है
  • system calls को कम करना, manifest binary caching, tarball extraction optimization, और OS native file copy जैसे कई स्तरों पर performance optimization को सक्रिय रूप से लागू किया गया है

Node.js और पैकेज मैनेजर आर्किटेक्चर की सीमाएँ

  • 2009 में Node.js के आने के बाद, event loop और thread pool आधारित asynchronous IO मॉडल पैकेज मैनेजरों तक भी फैल गया
  • उस समय hardware की सीमाएँ थीं, जैसे धीमी disk और धीमा network, इसलिए asynchronous IO और ज़्यादा system calls वाली रणनीति उचित थी
  • लेकिन आधुनिक सिस्टम में NVMe SSD, तेज़ network, और high-performance CPU आम हो चुके हैं, और असली bottleneck अब IO नहीं बल्कि system call overhead है

System call और mode switch की लागत

  • जब कोई program file read जैसे काम की मांग करता है, तो उसे user mode से kernel mode में switch करना पड़ता है, और इस प्रक्रिया में महंगे CPU cycles (1000~1500 cycles) खर्च होते हैं
  • पैकेज इंस्टॉलेशन में मूल रूप से दसियों हज़ार से लेकर लाखों तक system calls लगते हैं, इसलिए सिर्फ़ context switching की लागत ही कई सेकंड का CPU समय खा सकती है
  • उदाहरण के लिए, React और उसकी dependencies को install करते समय npm लगभग 10 लाख, yarn 40 लाख, pnpm 5 लाख, और bun 1.6 लाख system calls का उपयोग करता है

मौजूदा पैकेज मैनेजर और Bun के दृष्टिकोण में अंतर

  • npm, pnpm, और yarn सभी Node.js आधारित हैं, जहाँ JavaScript को कई abstraction layers (libuv, event loop, thread pool, system call mediation) के ज़रिए चलाना पड़ता है
  • इस दौरान argument conversion, worker pool queue, event loop task branching, और futex (lock synchronization) system calls जैसी चीज़ें जुड़ती जाती हैं, जिससे IO से ज़्यादा system call management ही धीमा पड़ जाता है
  • Node.js में बने पैकेज मैनेजर इस संरचनात्मक सीमा के कारण वास्तविक native-जैसा प्रदर्शन हासिल करना मुश्किल पाते हैं

Bun: Zig में बना native install engine

  • Bun Zig भाषा में सीधे system calls को invoke करता है, इसलिए JavaScript engine और abstraction layers पूरी तरह हट जाती हैं
  • उदाहरण के लिए file read करने के लिए Zig code सीधे openat() system call चलाता है और तुरंत data लौटा देता है
  • इसलिए दसियों हज़ार files पढ़ने की प्रक्रिया किसी अलग thread pool, event loop, या data conversion के बिना बहुत तेज़ चलती है
  • benchmark में Bun प्रति सेकंड 146,057 package.json files पढ़ सकता है, जबकि Node.js लगभग 60,000 के स्तर पर है, यानी 2 गुना से अधिक धीमा

Dependency management और DNS optimization

  • Bun, bun install चलाते समय dependency analysis के साथ-साथ DNS prefetch को asynchronous रूप से trigger करता है
  • उदाहरण के लिए macOS पर यह Apple की non-official async DNS API (getaddrinfo_async_start()) का उपयोग करता है, जिससे thread blocking के बिना network tasks को साथ-साथ चलाया जा सकता है
  • मौजूदा पैकेज मैनेजर libuv thread pool पर निर्भर रहते हैं, जहाँ अंदर से वास्तव में blocking code चलता है और resources बर्बाद होते हैं

Package manifest binary caching

  • npm आदि manifest को JSON के रूप में cache करते हैं, लेकिन Bun एक बार parse करने के बाद उसी परिणाम को binary (.npm file) में बदलकर स्टोर करता है
  • string duplication और parsing overhead कम होता है, और memory में offset calculation के ज़रिए सीधे values तक पहुँचा जा सकता है, इसलिए नए objects बनाने, parsing, या garbage collection की ज़रूरत नहीं पड़ती
  • ETag और If-None-Match headers से सिर्फ़ बदलाव की जाँच की जाती है, जिससे अनावश्यक data parsing के बिना freshness verify की जा सकती है
  • benchmark में Bun का cached install, npm के fresh install से भी तेज़ है

Tarball (compressed file) processing performance

  • सामान्य पैकेज मैनेजर tarball को stream के रूप में लेते हैं, और buffer memory कम पड़ने पर बार-बार reallocation, copy, और resize होता रहता है
  • Bun पूरा tarball receive करने के बाद उसे unpack करता है, और gzip के आख़िरी 4 bytes से uncompressed size पहले से पता कर लेता है, इसलिए सिर्फ़ एक बार memory allocate करनी पड़ती है
  • libdeflate आदि का उपयोग करके extraction तेज़ की जाती है, और अनावश्यक duplicate copy तथा size resize दोनों हटा दिए जाते हैं

Dependency graph और data structure optimization

  • पारंपरिक पैकेज मैनेजर JavaScript objects और pointers पर आधारित dependency tree बनाते हैं, जिससे memory random रूप से बिखरती है और CPU cache misses बार-बार होते हैं (pointer chasing समस्या)
  • Bun Structure of Arrays (SoA) pattern अपनाता है, जिसमें सभी packages, strings, और dependencies को बड़े लगातार memory blocks में रखा जाता है
    • offset/length आधारित access से CPU एक बार में कई packages को cache line स्तर पर पढ़ सकता है, यानी यह एक cache-friendly संरचना है
    • lockfile को भी JSON/YAML के बजाय SoA pattern के अनुकूल रखा जाता है, ताकि string deduplication और sequential memory access आसान हो
  • lockfile का binary format (bun.lockb) प्रयोगात्मक रूप से लाया गया था, लेकिन Git सहयोग में कमी आने के कारण इसे अधिक readable plain format में बदल दिया गया

OS-विशिष्ट file copy optimization

macOS

  • clonefile का उपयोग: पूरे directory को Copy-On-Write तरीके से एक ही system call में clone किया जाता है
  • इससे disk space duplication कम होती है और install speed अधिकतम हो जाती है
  • clonefile विफल होने पर fallback के रूप में per-directory cloning और फिर copyfile तक क्रमिक fallback किया जाता है

Linux

  • पहले hardlink का प्रयास: नई file बनाए बिना मौजूदा file के लिए सिर्फ़ नया reference बनाया जाता है, इसलिए disk data move नहीं होता
  • hardlink संभव न हो तो Btrfs/XFS पर ioctl_ficlone के जरिए Copy-On-Write लागू किया जाता है
  • इसके बाद copy_file_range, sendfile, और अंत में सामान्य copyfile तरीके तक fallback किया जाता है

कुल मिलाकर

  • Bun ने system calls को कम करके, binary structures, OS optimization, और data structure सुधार के ज़रिए पैकेज मैनेजर की पारंपरिक performance सीमाओं को पार किया है
  • इससे ultra-fast install के साथ-साथ memory और CPU efficiency भी बेहतर होती है
  • मौजूदा Node.js आधारित मैनेजरों की तुलना में इसे project में बिना runtime बदले भी लागू किया जा सकता है, यानी compatibility बनी रहती है
  • यह बड़े codebase में कई मिनट लेने वाली install प्रक्रिया को milliseconds से लेकर कुछ seconds के भीतर लाने का अनुभव देता है
  • system, hardware, और OS स्तर के हिसाब से की गई इस तरह की optimization अध्ययन और संदर्भ के लिहाज़ से बहुत मूल्यवान है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-09-12
Hacker News राय

  • मैंने इस दावे की जांच करने की कोशिश की कि मेरा M4 Max MacBook, 2009 के मानकों के हिसाब से, TOP500 सुपरकंप्यूटरों में टॉप 50 के भीतर आता 2009 के TOP500 में आने के लिए 75 TFlop/s से अधिक प्रदर्शन चाहिए था M4 Max का FP32 प्रदर्शन 18.4 TFlop/s है, लेकिन TOP500 में FP64(LINPACK) का उपयोग होता है M2 benchmarks के आधार पर FP64, FP32 का लगभग 1/4 है, इसलिए लगभग 9 TFlop/s का अनुमान बनता है उस स्तर पर यह 2009 के TOP500 में नहीं आता 2009 TOP500 सूची देखें

    • अगर हर connection एक साथ कई I/O operations कर रहा हो, तो इसे हजारों connections से गुणा करना होगा मैंने सुना है कि servers लगभग 95% समय I/O wait में रहते हैं, लेकिन असल में यह पूरे server के लिए नहीं, individual thread के हिसाब से होता है वास्तविक servers में CPU उपयोग अक्सर 70~80% तक पहुंच जाता है, और इससे ऊपर tail latency तेजी से खराब होती है अगर full load पर CPU सिर्फ 5% उपयोग हो रहा है, तो parallel processes की कमी या memory shortage जैसी समस्या है यह तकनीकी रूप से छोटा detail है, लेकिन ऐसी गलती पोस्ट की विश्वसनीयता घटा सकती है (यह मैं Bun के fan के नज़रिए से कह रहा हूँ)

    • वह निष्कर्ष कुछ ऐसा लगा जैसे LLM ने hallucination कर दिया हो खासकर निष्कर्ष वाला हिस्सा LLM output जैसा महसूस हुआ "यह समझ आया कि benchmark किए गए package managers गलत नहीं थे, बल्कि अपने समय के हिसाब से सही समाधान थे" "इस बात पर ज़ोर दिया गया कि Bun का तरीका क्रांतिकारी होने से ज़्यादा, आज की speed को धीमा करने वाले कारणों को ठंडे दिमाग से देखने का परिणाम है" "package install का 25 गुना तेज़ होना कोई जादू नहीं, बल्कि modern hardware के हिसाब से tools बनाने का स्वाभाविक परिणाम है"

  • विषय जटिल होने के बावजूद इसे इतना आसान और सरल ढंग से समझाया गया कि बहुत अच्छा लगा आज भी जोश से भरे लोग status quo तोड़कर कठिन समस्याओं को चुनौती देते हैं, यह काबिले-तारीफ़ है हर महीने computer hardware आगे बढ़ता है, लेकिन software का और धीमा होना अस्वाभाविक लगता है काश efficient coding सब लोग और बेहतर करते

    • मुझे पता नहीं था कि bun Zig में लिखा गया है Zig काफी नई language है, इसलिए इसे real-world में गंभीर रूप से इस्तेमाल होते देखना दिलचस्प है

  • मैंने पहली बार bun इस्तेमाल किया और बहुत प्रभावित हुआ built-in server और SQLite की वजह से सिर्फ bun install करना पड़ता है, जिससे development काफी आसान हो जाता है मैं आमतौर पर सिर्फ vanilla js इस्तेमाल करता हूँ और node ecosystem मुझे खास पसंद नहीं था, इसलिए अब लगता है कि bun मुझे पहले ही आज़मा लेना चाहिए था

    • मैंने Bun कई बार आज़माया है और उसका उपयोग अनुभव बहुत संतोषजनक रहा यह Node से बेहतर लगा लेकिन हर बार किसी न किसी निर्णायक समस्या से टकरा गया और आखिरकार Node पर लौटना पड़ा शुरुआत में crypto module, Nodejs के साथ compatible नहीं था (अब यह ठीक हो चुका है), और फिर Playwright, Bun पर काम नहीं किया

    • आजकल Node भी built-in server और SQLite support देता है अगर और features चाहिए हों, तो Hono भी एक अच्छा विकल्प है

  • लेख में Linux के hardlink और MacOS के clonefile को equivalent बताने वाला हिस्सा ठीक से समझ नहीं आया hardlink के मामले में, अगर एक copy को बदला जाए तो क्या सभी projects की files अनपेक्षित रूप से नहीं बदल जाएंगी?

  • तकनीकी रूप से काफी जटिल व्याख्या होने के बावजूद, इसे इतना पठनीय और आनंददायक ढंग से लिखा गया है कि प्रभावित हुआ

    • Lydia जटिल concepts को आसान तरीके से समझाने में बहुत सक्षम है मैंने उसका ज्यादातर काम और videos देखे हैं, और साफ महसूस होता है कि वह गहराई से तैयारी करती है अगर समय हो तो उसके articles और YouTube content ज़रूर recommend करूंगा हाल में शायद अपनी मौजूदा नौकरी की वजह से उसकी सक्रियता कम हुई है

  • Binary Manifest Caching सेक्शन में लगता है कि "npm (cached)" का benchmark time गायब है वहाँ bun, bun (cached), npm ही हैं, और summary stats भी ठीक से मेल नहीं खाते

  • इस पोस्ट की writing style मुझे बहुत पसंद आई io_uring के महत्व को समझाने के लिए यह लेख एक बहुत अच्छा उदाहरण बन सकता है सोच रहा हूँ कि Zig के हालिया v0.15 io updates, Bun की performance को अतिरिक्त फायदा दे सकते हैं या नहीं

  • मैं एक साल से ज्यादा समय से bun को लेकर उत्साहित हूँ मुझे लगा था कि 2025, bun के mainstream होने का पहला साल बनेगा, लेकिन हैरानी की बात है कि अभी भी यह उतना लोकप्रिय नहीं है GitHub के top 100k repos में, 2025 के हिसाब से नए repos में npm का उपयोग 35 गुना और pnpm का 11 गुना ज्यादा है Deno भी उम्मीद से उतना लोकप्रिय नहीं है वजह क्या हो सकती है? क्या runtime के लिए compatibility बनाए रखना, package manager की तुलना में ज्यादा कठिन है? जिन्होंने bun को आज़माया लेकिन अपनाया नहीं, उनकी राय सुनना चाहूंगा संबंधित आँकड़े संबंधित HN टिप्पणी

    • मैं Bun और Deno दोनों को पसंद करना चाहता था, इसलिए कई बार कोशिश की, लेकिन हर बार कोई निर्णायक खामी मिली और फिर इस्तेमाल जारी नहीं रख सका हाल में Bun में जो सबसे बड़ी समस्या मिली, वह streams के समय से पहले बंद हो जाने की issue थी संबंधित issue लिंक Deno में memory leak की समस्या मिली संबंधित issue लिंक आखिरकार लगता है कि Node ecosystem, Bun/Deno के फायदों को पहले ही अपना लेगा

    • Bun एक नया खिलाड़ी है, जिसे नया venture capital funding मिला है, और वह एक validated open source mainstream product (Node) से प्रतिस्पर्धा कर रहा है lock-in की incentives मौजूद हैं, और अंततः यह Node से बुनियादी रूप से बहुत अलग भी नहीं है इसकी strategic strength बहुत स्पष्ट नहीं है, और यह ऐसा कुछ नया नहीं देता जो Node से किया ही न जा सके मैंने इसे गंभीर रूप से इस्तेमाल होते नहीं देखा, सिर्फ हल्के उपयोग के मामलों में देखा है

    • issue tracker देखने पर लगता है कि शायद Zig भाषा बहुत safe नहीं है, इसलिए crashes अक्सर होते हैं मैं Node पर ही बना रहूँगा

    • मैं भी दूसरों की राय जानना चाहता हूँ मेरे हिसाब से Node एक project के रूप में mature है, democratic है, और community-driven महसूस होता है io.js fork वाला दौर भी इसने अच्छे से पार किया इसके उलट bun और deno, दोनों VC-backed projects हैं, इसलिए वे उतने democratic community-led नहीं लगते

    • मैं Bun का बड़ा fan हूँ मैं जहाँ संभव हो, हर project में Bun इस्तेमाल करता हूँ, और तरह-तरह के one-off scripts भी Bun/TS में लिखता हूँ लेकिन कुछ कम संख्या में, पर चिंताजनक issues हैं, इसलिए production deployment को लेकर अभी भी झिझक है उदाहरण के लिए, जब एक साधारण Express web server को Docker में चलाया, तो bun से run करने पर वह freeze हो गया सिर्फ node पर बदलने से सब ठीक चलने लगा एक साल पहले Bun + Prisma संयोजन में memory leak की वजह से server crash होने की समस्या भी थी (शायद अब तक ठीक हो गई होगी) इसके बावजूद Bun इतना पसंद है कि इन कमियों को सहकर भी कुल मिलाकर development time बचाता है transpile, modules, workspaces जैसी चीज़ों में इसकी convenience बहुत बड़ी है यह अभी npm जितना mainstream नहीं हुआ, यह भी पूरी तरह समझ में आता है

  • यह लेख पढ़ना बहुत आनंददायक था यह software development में computer science के सिद्धांत वास्तव में कितने महत्वपूर्ण हैं, इसका अच्छा उदाहरण है Big O, temporal/spatial locality, algorithm complexity, user/kernel space, file system, copy-on-write आदि ऐसे low-level package development में CS program में पढ़ाए जाने वाले लगभग सभी concepts सचमुच उपयोग में आते हैं

    • यह असल में computer science (CS) से ज्यादा software engineering (SE) के करीब है CS गणना और सिद्धांत का अध्ययन करता है (programming languages, algorithms, cryptography, machine learning आदि) जबकि SE, scalable और reliable software बनाने के लिए engineering principles लागू करता है

  • मुझे अब भी ठीक से समझ नहीं आया कि compressed file को पूरा पढ़ लेने के बाद ही extract होने का इंतज़ार करना क्यों बेहतर है मेरा अनुमान है कि download पूरा होने से पहले decompression शुरू करना, memory recopies बढ़ने के नुकसान से ज्यादा फायदे का सौदा हो सकता है