zlacker

[parent] [thread] 8 comments
1. smarna+(OP)[view] [source] 2025-12-02 19:56:20
Twice as fast at executing JavaScript? There's absolutely zero chance this is true. A JavaScript engine that's twice as fast as V8 in general doesn't exist. There may be 5 or 10 percent difference, but nothing really meaningful.
replies(4): >>johnfn+B5 >>ukblew+X5 >>jasnel+2i >>oscarg+fz3
2. johnfn+B5[view] [source] 2025-12-02 20:23:32
>>smarna+(OP)
You might want to revise what you consider to be "absolutely zero chance". Bun has an insanely fast startup time, so it definitely can be true for small workloads. A classic example of this was on Bun's website for a while[1] - it was "Running 266 React SSR tests faster than Jest can print its version number".

[1]: https://x.com/jarredsumner/status/1542824445810642946

replies(1): >>smarna+k31
3. ukblew+X5[view] [source] 2025-12-02 20:24:33
>>smarna+(OP)
It depends on what. Bun has some major optimisations. You’ll have to read into them if you don’t believe me. The graphs don’t come from nowhere
4. jasnel+2i[view] [source] 2025-12-02 21:25:59
>>smarna+(OP)
Keep in mind that it's not just a matter of comparing the JS engine. The runtime that is built around the engine can have a far greater impact on performance than the choice of v8 vs. JSC vs. anything else. In many microbenchmarks, Bun routinely outperforms Node.js and Deno in most tasks by a wide margin.
replies(1): >>smarna+X31
◧◩
5. smarna+k31[view] [source] [discussion] 2025-12-03 03:35:44
>>johnfn+B5
I only claimed there is absolutely zero chance that Bun is twice as fast at executing general JavaScript as Deno. The example doesn't give any insight into the relative speeds of Bun and Deno, as fast as I can tell.
replies(1): >>johnfn+Mg1
◧◩
6. smarna+X31[view] [source] [discussion] 2025-12-03 03:41:54
>>jasnel+2i
The claim I responded to is that Bun is "at least twice as fast" as Deno. This sounds a lot more general than Bun being twice as fast in cherry-picked microbenchmarks. I wasn't able to find any benchmark that found meaningful differences between the two runtimes for real-world workloads. (Example: https://hackernoon.com/myth-vs-reality-real-world-runtime-pe...)
replies(1): >>Aeolun+v81
◧◩◪
7. Aeolun+v81[view] [source] [discussion] 2025-12-03 04:32:54
>>smarna+X31
Real world benchmarks include database queries and http requests? That’d quickly obviate any differences between runtimes.

Lol, yeah, this person is running a performance test on postgres, and attributing the times to JS frameworks.

◧◩◪
8. johnfn+Mg1[view] [source] [discussion] 2025-12-03 06:23:03
>>smarna+k31

    johnfn@mac ~ % time  deno eval 'console.log("hello world")'
    hello world
    deno eval 'console.log("hello world")'  0.04s user 0.02s system 87% cpu 0.074 total
    johnfn@mac ~ % time   bun -e 'console.log("hello world")'
    hello world
    bun -e 'console.log("hello world")'  0.01s user 0.00s system 84% cpu 0.013 total
That's about 560% faster. Yes, it's a microbenchmark. But you said "absolutely zero chance", not "a very small chance".
9. oscarg+fz3[view] [source] 2025-12-03 20:29:03
>>smarna+(OP)
We are in the "system engineering territory" and as such it might have more to do with the way the runtime is designed and how the javascript native runtime does things than the compiler optimizations. You have to measure syscalls, memory access, cpu cache locality and a bunch of design decisions that in the end contribute a lot to the running time. So depending on the decisions taken, it can easily happen.
[go to top]