Bun & Deno Comparision

[ronag]

It would be nice to have some benchmarks vs Bun and Deno with things we would like to make faster. It provides some incentive and makes it more interesting to do perf work. Also a good indication of what things actually can be made faster

[benjamingr]

I agree, I also think it's important to measure actual user flows (kind of like what we did with boxbee for bluebird) and not micro-benchmarks.

[anonrig]

I've been using my own micro-benchmarks which helped me a lot: http://github.com/anonrig/node-benchmarks

[anonrig]

I can move my benchmark repository to this repository and start creating a suite of benchmarks against Bun & Deno and Node. wdyt? @ronag

[tniessen]

I also think it's important to measure actual user flows (kind of like what we did with boxbee for bluebird) and not micro-benchmarks.

I agree with @benjamingr. It would be great to benchmark some realistic applications instead of only using micro-benchmarks, and then using profiling to find out why Node.js is slower for those particular applications (if it is). Micro-benchmarks are great for what they are, but they don't say anything about real-world impact of performance optimizations.

[nassau-t]

Just my 2 cents,

Regarding Bun, in their github https://github.com/oven-sh/bun, you can see

In the case of nodejs, in github https://github.com/nodejs/node, you can see

So, Bun has A LOT of things implemented in Zig ("similar" to C++). I don't know if this is the way to follow, but it's obvious that it's impossible to get same performance of Zig or C++ with javascript code.

I think the best card of nodejs it's his API and the npm packages. Without this there is no game. That's why deno and bun try to be compatible with Nodejs, because without that, they have nothing.

I have posted this comment (in a good mood, and trying to be constructive) to record why I think bun is so fast.

[tniessen]

it's obvious that it's impossible to get same performance of Zig or C++ with javascript code.

@nassau-t It's not as simple as you make it sound. With the V8 JavaScript engine, some operations are faster when implemented in JavaScript as opposed to C++, primarily because of significant overheads within the V8 engine when crossing the JavaScript/C++ boundary. This is why V8 added "fast API calls", which reduce said overhead, but due to technical constraints, they can only reasonably be used for a fraction of Node.js APIs so far.

Of course, it's no secret that Bun's performance advantage comes, at least in part, from its reliance on Zig and the tight integration with JavaScriptCore. This is not a low barrier to contributors, and more than 75 % of all commits so far have been authored by the same person.

Hypothetically, Node.js could move a lot of logic from JavaScript to C++, and we would likely see performance improvements in some areas. I am not generally opposed to this (and it would solve a variety of other issues), but it would raise the barrier to contributing to Node.js because Node.js tends to have more contributors who are comfortable working on JavaScript than contributors who like writing C++.

Anyway, this issue is about adding benchmarks for comparing the performance across JavaScript runtimes. It is not the right place to discuss why you think one runtime is faster than another. Please open a new issue if you'd like to share more thoughts.

[nassau-t]

Anyway, this issue is about adding benchmarks for comparing the performance across JavaScript runtimes. It is not the right place to discuss why you think one runtime is faster than another. Please open a new issue if you'd like to share more thoughts.

Maybe doing benchmarks without thinking about what makes a thing faster than other it's a nonsense. Example: You cannot compare the amount of earth that can be moved with a bucket than with a mechanical shovel.

[tniessen]

Maybe doing benchmarks without thinking about what makes a thing faster than other it's a nonsense.

How do you know which one is faster than the other without doing benchmarks in the first place?

[nassau-t]

How do you know which one is faster than the other without doing benchmarks in the first place?

Suppose you and I do a benchmark to see who moves faster. (You on foot and me on a motorcycle, but don't take it into account yet). What is the meaning of the benchmark? Do you hope at some point to go faster on foot than I can on a motorcycle?

Speed can be improved, and must be improved, but knowing the conditions.

And as I already said, Nodejs greatest asset is its API and npm packages. As long as others don't have this, they have NOTHING.

[ronag]

This issue is about creating benchmarks. Please stay on topic.