3 ms·

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 bas

by culi 4y ago

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)

franciscop 4y ago
It's worth noting that the main people I've seen complaining about those benchmarks were people working on Deno or Node :)
- fennecfoxy 4y ago
  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.
- culi 4y ago
  This is mostly true but I've also yet to see any independent party try to benchmark the runtimes
  - franciscop 4y ago
    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.
hajile 4y ago
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.
- culi 4y ago
  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)
  - hajile 4y ago
    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-performance-bun-vs-node-js-2c9d383b94c1 https://medium.com/deno-the-complete-reference/hello-world-p... https://medium.com/walmartglobaltech/react-native-memory-profiling-jsc-vs-v8-vs-hermes-1626949a653b https://medium.com/walmartglobaltech/react-native-memory-pro...
    - culi 4y ago
      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-performance-comparison-for-api-proxy-bf89ec3571be https://medium.com/deno-the-complete-reference/deno-vs-bun-p...
henry_viii 4y ago
> benchmarks done by an independent party From another comment: https://news.ycombinator.com/item?id=34437276 https://news.ycombinator.com/item?id=34437276

by culi 4y ago

franciscop 4y ago

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

fennecfoxy 4y ago
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.
culi 4y ago
This is mostly true but I've also yet to see any independent party try to benchmark the runtimes
- franciscop 4y ago
  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.

hajile 4y ago

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.

culi 4y ago
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)
- hajile 4y ago
  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-performance-bun-vs-node-js-2c9d383b94c1 https://medium.com/deno-the-complete-reference/hello-world-p... https://medium.com/walmartglobaltech/react-native-memory-profiling-jsc-vs-v8-vs-hermes-1626949a653b https://medium.com/walmartglobaltech/react-native-memory-pro...
  - culi 4y ago
    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-performance-comparison-for-api-proxy-bf89ec3571be https://medium.com/deno-the-complete-reference/deno-vs-bun-p...

henry_viii 4y ago

> benchmarks done by an independent party From another comment: https://news.ycombinator.com/item?id=34437276 https://news.ycombinator.com/item?id=34437276