bun install ~2x slower than npm install in docker build

[adamjberg]

What version of Bun is running?

1.0.1+31aec4ebe325982fc0ef27498984b0ad9969162b

What platform is your computer?

Linux 6.2.0-32-generic x86_64 x86_64

What steps can reproduce the bug?

This seems to be across the board for me, but the example below uses a create-react-template to demonstrate how severe this gets with lots of dependencies.

Create CRA Template

bun create react-app my-react-app

Node/NPM Dockerfile

# Dockerfile.npm
FROM node:alpine

WORKDIR /app

COPY package.json package-lock.json ./

RUN npm install

docker build -t npm-cra -f Dockerfile.npm .

Bun Dockerfile

# Dockerfile.bun
FROM oven/bun

WORKDIR /app

COPY package.json package-lock.json ./

RUN bun install

docker build -t bun-cra -f Dockerfile.bun .

What is the expected behavior?

When running outside of Docker, npm takes 5 second and bun takes 1 second. I would expect that inside the docker build bun outperforms the npm install.

What do you see instead?

The npm install inside Docker takes 12 seconds
The bun install inside Docker takes 29 seconds

Additional information

No response

[Electroid]

Thanks for making this issue, we should be able to make it much faster on Docker. Are you just running docker locally? Or are you running it using a service?

[adamjberg]

These numbers are from running locally

[GiGurra]

I am having the same issue - the install command in docker is slower than with regular npm.
But it is a bit random. Sometimes it is only 5-10% slower. This is about half the executions.

Then the remaining executions take 2x the time. It just sits idle in "resolving dependencies". Perhaps bun has less aggressive retry logic than npm?

FYI/off topic: my next builds (bun run build) are also slightly slower than with npm (about 5%)

[adamjberg]

Tried on another Ubuntu machine and got the expected results. I have a feeling this could be Docker version related. Tomorrow I can update with the Docker version of the machine having the performance discrepancy.

Platform: Linux 5.15.0-76-generic x86_64 x86_64

Docker version 24.0.4, build 3713ee1

NPM: 17.5 seconds
BUN: 12.9 seconds

I tried this on my Mac and the results are more in line with what I would expect.

Platform: Darwin 22.5.0 arm64 arm
Docker version 24.0.5, build ced0996

NPM: 9.5 seconds
BUN: 6.7 seconds

[adamjberg]

The machine from the original report was running:

Docker version 24.0.6, build ed223bc

[rafaell-lycan]

Same issue here, with the latest versions of Node & Bun.

For context, this is a production API (Express, Zod, Drizzle, Postgres, etc)

Docker version 23.0.1, build a5ee5b1dfc
macOS version 13.5, build 22G74

Node (node:20.7-alpine3.18 + pnpm): 10.2s
Bun (oven/bun:1.0.3): 12.77s

Out of curiosity, is Bun's image using the Alpine distro underneath? cc @Electroid @Jarred-Sumner

[Electroid]

@rafaell-lycan The oven/bun docker image uses a Debian-slim image.

[ciekawy]

I did try bunlovesnode/bun:1.0.0-node18 and it was much faster - for my particular case:

• npm up to ~300s
• bunlovesnode/bun ~75s (experiencing segfault later)
• oven/bun ~320s (fails at resolving cypres)
• pnpm 125s - all is working!

[Jarred-Sumner]

#10037 fixed a deadlock that could in theory occur and may be related to this

[0tii]

Still regularly encountering exceptionally slow installs in docker container. Almost always the install runs for pretty exactly 300 seconds plus a few. To me this looks like a 5 minute timeout that it reliably runs into.

Just did a fresh build

[+] Building 311.1s (9/9) FINISHED                                                                                                                                                                            docker:default
 => [app internal] load build definition from Dockerfile                                                                                                                                                                0.1s
 => => transferring dockerfile: 366B                                                                                                                                                                                    0.0s
 => [app internal] load metadata for docker.io/oven/bun:1.1.4                                                                                                                                                           1.7s
 => [app internal] load .dockerignore                                                                                                                                                                                   0.1s
 => => transferring context: 74B                                                                                                                                                                                        0.0s
 => [app base 1/3] FROM docker.io/oven/bun:1.1.4@sha256:ea572eace71acadb17ea5c408550eafd5ab82f2f6f48c04b906a3091e017cf35                                                                                                0.0s
 => [app internal] load build context                                                                                                                                                                                   0.1s
 => => transferring context: 323.06kB                                                                                                                                                                                   0.0s
 => CACHED [app base 2/3] WORKDIR /usr/src/app                                                                                                                                                                          0.0s
 => [app base 3/3] COPY package.json bun.lockb ./                                                                                                                                                                       0.2s
 => [app dev 1/1] RUN bun i --frozen-lockfile                                                                                                                                                                         305.4s
 => [app] exporting to image                                                                                                                                                                                            3.1s 
 => => exporting layers                                                                                                                                                                                                 3.0s 
 => => writing image sha256:121438b6f47052001fa692753430f3335057762e7b6deadc243cae13ff902157                                                                                                                            0.0s 
 => => naming to docker.io/library/cannahub-backend-app                                                                                                                                                                 0.0s 

using a plain dockerfile

FROM oven/bun:1.1.4 as base
WORKDIR /usr/src/app
COPY package.json bun.lockb ./

FROM base as dev
RUN bun i --frozen-lockfile

COPY . .
CMD ["bun", "start:dev"]

for CI/CD this is unbearable

[Jarred-Sumner]

I really wish I knew how to reproduce this. My best guess right now is DNS. Perhaps issue with IPv6 vs IPv4. If you try using 8.8.8.8 or 1.1.1.1 for DNS it might fix itself.

If the destination drive is a network drive like NFS or Windows via WSL, that would also explain it. We do lots of synchronous I/O in bun install which is often faster the disk is fast but slower when the disk is slow

[0tii]

If the destination drive is a network drive like NFS or Windows via WSL, that would also explain it.

For me personally i do use WSL, but docker engine and the projects themselves are fully on the linux side, nothing on the host.

My best guess right now is DNS.

Can you elaborate on this, afaik docker uses the host DNS, which would be the one configured on my WSL instance not host system? Or where am I supposed to change the DNS?

[Jarred-Sumner]

happy eyeballs, DNS caching have been implemented - #11206

If this is still not fixed, please let us know and we'll re-open the issue.

[Cyberlane]

@Jarred-Sumner I have this exact issue (although it's more than 2x, closer to 10x).
It took me 275s to install what it almost instant outside of Docker.

I replicate it 100% of the time on my machine, is there any data I can obtain for you that can help diagnose what's going on?

Some basic technical info about the machine with the issue:

Apple M2 Max
macOS Sonoma 14.5
Docker with Colima

I've tried numerous different versions of Bun for the last few weeks, hoping it would eventually just get solved, but unfortunately not. I've just tried again now with 1.1.26 and it still has the issue.
More than happy to provide whatever data dumps you want/need, Dockerfile, package.json, just let me know what I can do to help.

[ciekawy]

when running bun with verbose there are definitely long delays between fetching so seems like the networking issue is not resolved.

Also with some dns tweaks I managed to make it mostly very fast but out of sudden it stuck on one of last files for over a minute... this is random of course

[Cyberlane]

@ciekawy I notice it 100% of the time on my personal machine (macOS), however when I push the Dockerfile up to a Linux machine, it works just fine.

So I am kind of curious if Colima or macoS or something alone those lines is perhaps to blame...
Your DNS changes, did you make them within the Docker service, or with the OS?

[ciekawy]

Well there is no issues with any of npm, yarn, pnpm. Neither I notice any similar problems with any other services and I use dozens of docker images for my work...
It definitely may be some combination of both. For macOS and docker in the past there was just known issue with filesystem events but that has been solved more than a year ago.

[ciekawy]

As for dns changes actually after verification, the only change that possibly makes real difference (the practical case I care about is docker build) is --network host, this may still be some subjective observation but seems like it works somewhat better.

Considering bun itself being in general considerably faster I'd guess it would benefit from some batching optimizations eg keepalive to fetch number of deps and similarly as for disk access.