Да ладно, вы и вправду подумали что я просто так это всё оставлю и не попытаюсь детально разобраться в чем же причина такой мега-скорости Bun?
В первую очередь мой острый взгляд пал на React - и в принципе я не прогадал: в марте вышло обновление 18.0 и в нём переделали Stream'ы для Nodejs в серверном рендеринге. Моментально я наткнулся на следующий Issue в github где чувак обратил внимание на то, что у него деградировал перформанс чуть ли не в 5 раз!
Почему это важно? Да всё просто - в Node используется своя версия реализации стриминга. В Deno используется другая реализация. А вот в Bun вообще нет официальной поддержки - авторы используют самопальный polyfill для стриминга отрендеренной страницы.
Поэтому, переписав код бенчмарка и заменив функцию
renderToPipeableStream на renderToString результат Nodejs заметно улучшился и разрыв в среднем сократился уже до 25% — заметь, это не 300% разницы и даже не мои изначальные 45%, по результатам самых первых тестов.Собственно продолжив копаться дальше, я обратил внимание на следующий момент: Bun с какой-то стати игнорирует Http заголовки которые указаны в бенчмарке — а Nodejs в свою очередь наоборот ДОБАВЛЯЕТ лишние заголовки. В итоге разница составляла в среднем: ~130 байт данных, которые приходилось гонять ноде.
Разбираться почему Bun игнорирует заголовки - я не стал, пусть этим разработчики занимаются. Я в свою очередь просто привел Nodejs к тем же самым условиям - важно чтобы заголовки совпадали по размеру, для чистоты эксперимента.
В итоге разрыв сократился до 18-20% в пользу Bun — это мой максимум. Я не использовал никаких кастомных Http серверов, для меня было важно использовать средства чистой Node.js
Более того, если из этих переменных выкинуть React SSR и оставить голые байтики - разрыв будет точно таким же. Я понятия не имею каким образом сетевой код у разработчика Bun вышел на столько производительней, но факт остаётся фактом — это 20% дополнительного перформанса только за счёт I/O.