macOS taking ages to start my app for unknown reasons

[touhidurrr]

What version of Bun is running?

1.1.15-canary.1+3ff29955a

What platform is your computer?

Github Actions macos-latest or macos-13 runner

What steps can reproduce the bug?

see: https://github.com/touhidurrr/newServer/actions/runs/8657287140 https://github.com/touhidurrr/newServer/blob/de4bf7233eea85c62bda3da42489926e41a7bea7/tests/start.test.ts

What is the expected behavior?

No Errors

What do you see instead?

Test Timeout

Additional information

I have tried many things but this test is failing randomly for unknown reasons. Note that os.hostname() here is making the code more performant. Without it linux and windows fails also.

[joakimbeng]

I'm experiencing the same issue locally on my Mac (M1 with macOS 14.4.1), since at least Bun v1.0 (I'm on 1.1.0 now). Every Bun command takes many seconds just to start. And for instance a bun install can report an install time of 7 seconds, but the actual measured time is about 40 s.

Don't know what's causing it, and don't know how to debug it either...

[touhidurrr]

And for instance a bun install can report an install time of 7 seconds, but the actual measured time is about 40 s.

Now this is interesting. How can time measurement be wrong... Very weird.

Don't know what's causing it, and don't know how to debug it either...

Same for me. Glad to hear that someone shares the same feelings as me. Since I do not have a Mac machine to test it myself. And in GitHub Actions, it works on both Windows and Linux anyway*, I just removed the macOS test from my project as it was wasting my effort to debug it.

But I do have some suspicions as to why it happens. Bun is terrible at determining how to choose DNS or HTTP requests or maybe both especially when it is behind a firewall or VPN. bun install takes ages to install even a single dependency whenever I turn on Cloudflare Wrap on my PC. Maybe on Mac, this is more broken?

I think Bun should also prioritize fixing memory leaks and stability issues such as this. It appears to me that they are wasting more effort at trying to make Bun appear cool instead of making it more stable regardless of whatever they say their priorities are.

Introducing new features is not bad but attention to stability improvements and introduction of new features should at least be split to 50/50.

I switched to bun on production on my personal project (technically it gets ~800k unique visitors per month even though I say it is a personal project for the lack of open source interest in contributing to it) and sincerely hate it. Uptime dropped from 99.9% to 99.7% for a memory leak issue that I couldn’t fix.

I can at least testify that many issues with Bun on production and trying to debug them only to find out it might be related to the runtime to begin with has wasted more time than I thought I would save when I rewrote my project with bun. Even though the project itself is not that complicated.

I still like Bun and the utility and simplicity it offers, but hate how it is riddled with so many runtime issues.

Anyways, enough nagging. Maybe I got excited finding out that other people are also facing the same problems as me and the fact that I am not alone regarding this matter.

[joakimbeng]

But I do have some suspicions as for why it happens. Bun it terrible at determining how to chose DNS or http requests or maybe both specially when it is behind a firewall or VPN. bun install takes ages to install even a single dependency whenever I turn on Cloudflare Wrap on my PC. Maybe on mac this is more broken?

You may be on to something there! I'm often connected to the company's vpn when I work (all of our installs go through a private npm mirror, and we have a shared dev database). But the weird thing is that it's not just the installs that take a long time, every Bun command takes a significant time to start to a degree that's really annoying!

In one project running time bunx --bun eslint ./ is finished in a total time of 2 min and 30 seconds(!), whereas running time npx eslint ./ in the same project is finished in just 6 s! When running the linting using Node, the time is stable at about 6 s every time. But with Bun it varies on every run, for instance 2m 31s, 22s, 12s, 6s, 19s...

[Jarred-Sumner]

Related #10731

[touhidurrr]

Related #10731

Still facing with bun canary 1.1.15-canary.1+3ff29955a release. Action file: https://github.com/touhidurrr/UncivServer.xyz/blob/touhidurrr-actions-macos-latest-test/.github/workflows/test.yml Failed run: https://github.com/touhidurrr/UncivServer.xyz/actions/runs/9581349796