3 ms·
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
by 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 agov8 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 agoWow 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...