Hacker News Reader

Hacker News

Comment by thiago_fm | Hacker News Reader

Parent Full thread

thiago_fm

Anybody care to explain on how it achieve such numbers in comparison to node and deno?

Why would anybody not use Bun, other than the cost of migration, given the performance improvement?

Nevertheless, amazing performance. Feels refreshing to see more improvements to the JS/TS community.

View on HN

We spend an absurd amount of time profiling, benchmarking, and making stuff run fast in Bun

Most of Bun is written in native code (zig) rather than JavaScript. We leverage modern CPU features like SIMD, closely watch syscall overhead and spend a lot of time reading about system calls and platform-specific system APIs

Bun is still pretty early - we are not at 1.0 yet. There are crashes and many bugs to fix, but we are making steady progress towards a stable release

I think the main difference is that while Node and Deno embed Chrome's V8 engine, Bun embed's Apple's JavaScriptCore. Bun also uses "a new JavaScript parser based on esbuild’s JavaScript parser but ported to Zig"

However, it's worth noting that those benchmarks have been critized a lot for being cherry-picked and not very representative of real-world use-cases

I've tried to look it up a number of times but I've yet to come across any benchmarks done by an independent party (please share if you find some)

It's worth noting that the main people I've seen complaining about those benchmarks were people working on Deno or Node :)

I'd complain about them and I don't work on either of those projects.

But I have worked _with_ node for a very long time, and I am intensely familiar with the JS ecosystem's "flavour of the day" culture.

I think people are rightfully suspicious of such bold claims. Particularly as Deno came out to much fanfare and self promotion but like...I barely hear of anyone actually using it in production as opposed to node.

Not saying that node will be King forever, just that I'm taking a grain of salt.

This is mostly true but I've also yet to see any independent party try to benchmark the runtimes

Agreed! Just noting that there's conflict of interests all around the place, not just on one side.

What seems clear though is that Bun/Jarred really care about performance, since it's a big part of the tweeting/public communication. Maybe the tests are not the best from a real-world comparison, but the fact that he's constantly trying to make every small thing high performance would suggest that performance IS important for Bun. So people might disagree on "how much better", but I'd not be surprised at all if a system built from the ground up with a big focus on performance is faster than the competition.

In my general experience, JSC is 20-50% faster in a lot of things, but uses about 2x the memory. I'm not sure how much of that is memory/speed tradeoff, but I suspect a lot of it is "we spent our budget on fast and skipped working on a better garbage collector".

It's probably a decent tradeoff in a lot of applications, but probably not in all of them.

The memory usage difference you're seeing is likely a GC scheduling issue in Bun (not a JS engine thing)

Bun isn't scheduling the garbage collector between microtask ticks and we might need to start doing that to reduce memory usage. We did that in Bun v0.3 for the event loop, but we didn't do it for the microtask queue.

Sounds like a common tradeoff just theoretically. Usually you can cache more things to increase speed aka increase space complexity to reduce time complexity. I don't think it's necessarily a sign that Apple skimped out on something but rather made a design decision

But you bring up a good point and I'd like to see a more holistic benchmark that takes both space and time complexity into account (preferably done by an independent party)

v8 is compacting while JSC is not. I think it's telling that v8 released a new GC in 2018 to massively improve their GC performance while in 2019 JSC redid their bytecode and execution engine to radically improve execution performance.

There's limited resources on each team and I suspect the biggest difference here is differing priorities for those resources. There's not many third-party comparisons, but here's two.

https://medium.com/deno-the-complete-reference/hello-world-p...

https://medium.com/walmartglobaltech/react-native-memory-pro...

Wow thanks for the links. The first one had a good comparison but only compared Bun and Node. However it's pretty telling that Bun's margins aren't nearly as significant as they are in the benchmarks being paraded around. Also seems like you're right about Bun using more memory to achieve faster speed

Edit: That same blog also did a comparison of Bun and Deno directly. Looks like Deno usually outperformed Bun pretty significantly:

https://medium.com/deno-the-complete-reference/deno-vs-bun-p...

I'm not saying you're wrong, but I'm having trouble squaring this analysis with Chrome's notoriously high memory usage compared to Safari. What's gunking up Chrome if not V8's memory needs?

The bulk of the browser's memory usage is the rendering engine and surrounding stuff rather than the JS on the page.

v8 has a compacting GC[0] while JSC does not[1]. This was the result of the v8 team taking out a bunch of time to write a new GC that was released in 2018 (Orinoco).

Here's a comparison of a simple job. With lots of concurrency, Bun is 20-30% faster, but uses 60% more memory.

https://medium.com/deno-the-complete-reference/hello-world-p...

Here's a little about JSC, Hermes, and v8 memory in React Native.

https://medium.com/walmartglobaltech/react-native-memory-pro...

[0] https://v8.dev/blog/trash-talk

[1] https://webkit.org/blog/12967/understanding-gc-in-jsc-from-s...

> Here's a comparison of a simple job. With lots of concurrency, Bun is 20-30% faster, but uses 60% more memory.

That benchmark is out of date. In Bun v0.3, memory usage in situations like that dropped by 4x - https://bun.sh/blog/bun-v0.3.0, meaning it uses around half as much memory as Node.

Prior to Bun v0.3, Bun wasn't scheduling the garbage collector in conjunction with the event loop and that led to memory not being reclaimed correctly on idle

This comparison uses Bun v0.4 and still often finds Deno ahead

https://medium.com/deno-the-complete-reference/node-js-vs-de...

> benchmarks done by an independent party

From another comment:

https://news.ycombinator.com/item?id=34437276

Jarred is approaching this from a fundamentally performance (due to targeting of Edge runtime) and DX perspective. If you follow his twitter or bun discord, you can see he spends an enormous amount of time studying, profiling, and tweaking features so he can squeeze as much performance out of it as he can.

Reasons not to use bun:

- it is pre v1, so unstable API

- it is unstable, so you will deal with crashes

- newer, so help articles will be hard to find

I would ask the other way ... why use Bun if the other products are mature and good enough? I've seen Node forked (to Deno I think) and then eventually they merged it back.

You might be thinking of io.js, which was a fork almost entirely due to politics. The advisory board came out of it, and a push for semver, but it started here: https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482d...

>I've seen Node forked (to Deno I think) and then eventually they merged it back.

You're thinking of the io.js debacle

Node forked to Deno? And merged... back? What are you talking about?

Reply on news.ycombinator.com