undefined | Better HN

0 pointshajile3y ago0 comments

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.

0 comments

7 comments · 3 top-level

culi3y ago· 2 in thread

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)

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

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

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

maxfurman3y ago· 2 in thread

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?

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

Jarred3y 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, 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

1 more reply

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

j / k navigate · click thread line to collapse

0 comments

7 comments · 3 top-level

culi3y ago· 2 in thread

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)

hajileOP3y ago

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

culi3y ago

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

maxfurman3y ago· 2 in thread

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?

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

Jarred3y 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, 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

1 more reply

Jarred3y ago

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

j / k navigate · click thread line to collapse