На конференциях про фронтенд часто спорят, какой менеджер пакетов быстрее: npm, pnpm или yarn. Но в 2025 году появился новый игрок, который разрубил этот спор как гордиев узел — Bun Install. Он работает в 4–17 раз быстрее конкурентов. В чём секрет? Не в «чудесах оптимизации на JavaScript», а в том, что Bun смотрит на установку пакетов как на задачу системного программирования.
⚡ Что замедляет установку пакетов
Традиционные менеджеры пакетов до сих пор живут в логике 2009 года: медленные HDD, скромные процессоры и вечное ожидание I/O. Именно тогда Node.js с его event loop казался глотком свежего воздуха.
Сегодня ситуация другая:
- 💾 SSD выдают до 7 000 MB/s,
- 🖥️ у ноутбука десятки ядер,
- 📶 интернет позволяет стримить 4K.
Но npm и yarn по-прежнему тратят миллионы системных вызовов (syscalls), каждый из которых требует 1000–1500 тактов CPU на переключение между user mode и kernel mode. В итоге, на простом yarn install процессор может сжечь миллиарды тактов впустую.
🔍 Почему Bun быстрее
Bun написан не на JS, а на Zig, и это сразу меняет картину:
- 🚫 Нет промежуточных абстракций Node.js и libuv.
- 📂 Прямые системные вызовы (openat, copy_file_range и т.д.).
- 🗂️ Бинарное кеширование манифестов вместо повторного парсинга JSON.
- 🗜️ Оптимизированное распаковка tarball: Bun заранее знает размер файла и выделяет память без копирования.
- 📚 Structure of Arrays вместо вложенных JS-объектов → данные лежат в памяти последовательно, без «pointer chasing».
- 🧵 Lock-free многопоточность: все ядра CPU работают одновременно, а не простаивают.
Результат: 165 000 системных вызовов у Bun против 4 млн у yarn.
🛠️ Детали, которые меня впечатлили
- 🍏 На macOS Bun использует clonefile(), создавая копии директорий в один syscall через copy-on-write.
- 🐧 На Linux — делает ставку на hardlinks, а если не получается, откатывается на ioctl_ficlone, copy_file_range или sendfile.
- 🌐 DNS-запросы Bun делает асинхронно на уровне ядра (macOS API getaddrinfo_async), а не через блокирующие вызовы libuv.
- 🔒 У каждого потока — свой memory pool, что убирает конкуренцию за аллокатор.
Эти оптимизации звучат как учебник по системному программированию. npm же до сих пор живёт в парадигме «один главный поток + thread pool».
🤔 Моё мнение
Для меня Bun — это не просто новый пакетный менеджер. Это демонстрация сдвига парадигмы: разработчики наконец-то начали писать инструменты не под ограничения прошлого (медленный I/O), а под возможности настоящего (SSD, многопоточность, дешёвая память).
Bun Install показывает, что:
🔹 «быстро» = «меньше системных вызовов, ближе к железу»;
🔹 современные CPU и ОС дают пространство для новых трюков (clonefile, lock-free структуры);
🔹 Node.js, каким бы революционным он ни был в 2009, стал тормозом для инструментов вокруг себя.
Я убеждён, что следующие 10 лет в разработке будут определять такие проекты, как Bun. Не те, кто «чуть ускорил npm», а те, кто заново посмотрел на задачу с учётом железа 2025 года.
📖 Источник: Behind the scenes of Bun Install