4 ms·

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 s

by 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...
maxfurman 4y ago
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?
- hajile 4y ago
  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-performance-bun-vs-node-js-2c9d383b94c1 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-profiling-jsc-vs-v8-vs-hermes-1626949a653b https://medium.com/walmartglobaltech/react-native-memory-pro... [0] https://v8.dev/blog/trash-talk https://v8.dev/blog/trash-talk [1] https://webkit.org/blog/12967/understanding-gc-in-jsc-from-scratch/ https://webkit.org/blog/12967/understanding-gc-in-jsc-from-s...
  - Jarred 4y ago
    > 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 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
    - culi 4y ago
      This comparison uses Bun v0.4 and still often finds Deno ahead https://medium.com/deno-the-complete-reference/node-js-vs-deno-vs-bun-server-side-rendering-performance-comparison-f80a5abc766f https://medium.com/deno-the-complete-reference/node-js-vs-de...
Jarred 4y ago
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.

by hajile 4y ago

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...

maxfurman 4y ago

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?

hajile 4y ago
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-performance-bun-vs-node-js-2c9d383b94c1 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-profiling-jsc-vs-v8-vs-hermes-1626949a653b https://medium.com/walmartglobaltech/react-native-memory-pro... [0] https://v8.dev/blog/trash-talk https://v8.dev/blog/trash-talk [1] https://webkit.org/blog/12967/understanding-gc-in-jsc-from-scratch/ https://webkit.org/blog/12967/understanding-gc-in-jsc-from-s...
- Jarred 4y ago
  > 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 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
  - culi 4y ago
    This comparison uses Bun v0.4 and still often finds Deno ahead https://medium.com/deno-the-complete-reference/node-js-vs-deno-vs-bun-server-side-rendering-performance-comparison-f80a5abc766f https://medium.com/deno-the-complete-reference/node-js-vs-de...

Jarred 4y ago

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.