Behind the Scenes of Bun Install

Summary

Running bun install is fast, very fast. On average, it runs ~7× faster than npm, ~4× faster than pnpm, and ~17× faster than yarn. The difference is especially noticeable in large codebases. What used to take minutes now takes (milli)seconds.These aren't just cherry-picked benchmarks. Bun is fast because it treats package installation as a systems programming problem, not a JavaScript problem.In this post we’ll explore what that means: from minimizing syscalls and caching manifests as binary, to optimizing tarball extraction, leveraging OS-native file copying, and scaling across CPU cores.But to understand why this matters, we first have to take a small step back in time.It's the year 2009. You're installing jQuery from a .zip file, your iPhone 3GS has 256MB of RAM. GitHub was just a year old, SSDs cost $700 for 256GB. Your laptop's 5400RPM hard drive maxes out at 100MB/s, and "broadband" means 10 Mbps (if you're lucky).But more importantly: Node.js just launched! Ryan Dahl is on stage explaining why servers spend most of their time waiting.In 2009, a typical disk seek takes 10ms, a database query 50–200ms, and an HTTP request to an external API 300ms+. During each of these transactions, traditional servers would just... wait. Your server would start reading a file, and then just freeze for 10ms.Now multiply that by thousands of concurrent connections each doing multiple I/O operations. Servers spent ~95% of their time waiting for I/O operations.Node.js figured that JavaScript's event loop (originally designed for browser events) was perfect for server I/O. When code makes an async request, the I/O happens in the background while the main thread immediately moves to the next task. Once complete, a callback gets queued for execution. Simplified illustration of how Node.js handles fs.readFile with the event loop and thread pool. Other async sources and implementation details are omitted for clarity. JavaScript's event loop was a great solution for a world where waiting...