I'm curious if the Node.js setup that resulted in these numbers was also the default single process, rather than the cluster setup that's included with Node, but not configured by default.
Deno vs. Bun performance is rigged
11–20 of 196 posts
Re: Deno vs. Bun performance is rigged
#12I think nobody should be surprised that two startups competing for more or less the same space end up fighting over benchmarks. My recommendation is to ignore all benchmarks altogether and simply run the tests yourself.
Re: Deno vs. Bun performance is rigged
#13Im surprised performance at this level even matters to most folks. Like if you truly thought this microbenchmark was the reason to choose one runtime over another Id be shocked. It makes it equally surprising that this error from the Deno crew, who should all know better. In either case, I hope they announce a correction and move on to more important matters. If youre trying to shave another tiny bit of rps out of yo…
Javascript is plagued with idea that it is slow while it is not. Many devs now have PTSR after arguing day after day that javascript is a good thing and not slow. Performance is a very important thing in js world for a peace of mind of devs.
To be fair it did used to be quite slow. But that was like 10 years ago. General awareness hasn't caught up to the huge engineering efforts it seems.
Re: Deno vs. Bun performance is rigged
#14Why isn’t bun utilising multiple cores?
I can’t find the tweet right now but I follow the developer on twitter and his rationale was essentially that he wanted to focus on nailing single core speeds before expanding to multi core. I assume this has to do with how extremely experimental bun is at the moment anyway. So they are focusing on nailing the fundamentals before attempting anything that would make it „production ready“ such as multi core support.
I have no idea if this is Bun's plan or not, but IMO there's nothing wrong in opting for a share-nothing architecture where you simply spin up one Bun process per core and let caddy/nginx/... handle the load balancing.
Re: Deno vs. Bun performance is rigged
#15Why isn’t bun utilising multiple cores?
I can’t find the tweet right now but I follow the developer on twitter and his rationale was essentially that he wanted to focus on nailing single core speeds before expanding to multi core. I assume this has to do with how extremely experimental bun is at the moment anyway. So they are focusing on nailing the fundamentals before attempting anything that would make it „production ready“ such as multi core support.
Ah yeah in the submitted article they say the updated benchmark used “latest Bun…” - so does that mean that it was just tested using a released version (lacking multithreading) instead of a nightly build (with recently added multithreading)?
As an aside, I’ve now seen a couple of HN submissions relating to Bun and there’s been a vibe that there’s conspiracy or foul play afoot in each. That’s a little … unusual. What does the developer seem like on Twitter, fairly normal or a bit eccentric?
Re: Deno vs. Bun performance is rigged
#16Why isn’t bun utilising multiple cores?
I can’t find the tweet right now but I follow the developer on twitter and his rationale was essentially that he wanted to focus on nailing single core speeds before expanding to multi core. I assume this has to do with how extremely experimental bun is at the moment anyway. So they are focusing on nailing the fundamentals before attempting anything that would make it „production ready“ such as multi core support.
Re: Deno vs. Bun performance is rigged
#17I'm surprised to read that "Bun actually sits above a URL router capable of matching methods, URL wildcards and parameters".
I thought bun was just a JS runtime, though I guess thinking about it maybe I don't even understand what a JS runtime is.
I always figured nodejs is v8 + an stdlib. I think bun is a custom zig-js engine + an extended stdlib (website claims "batteries included")?
Isn't the router generally "application/framework (i.e vue) specific"?
Does stuff like Express or Nextjs not actually ship a webserver and just use the underlying "runtime"'s `http.serve` function? Is it possible to make an analogous "webbrick to unicorn" server swap while still running nodejs or are you swapping runtimes to do that?
Re: Deno vs. Bun performance is rigged
#18Im surprised performance at this level even matters to most folks. Like if you truly thought this microbenchmark was the reason to choose one runtime over another Id be shocked. It makes it equally surprising that this error from the Deno crew, who should all know better. In either case, I hope they announce a correction and move on to more important matters. If youre trying to shave another tiny bit of rps out of yo…
Javascript is plagued with idea that it is slow while it is not. Many devs now have PTSR after arguing day after day that javascript is a good thing and not slow. Performance is a very important thing in js world for a peace of mind of devs.
I agree performance is important, but it’s optimistic for any dev to assume that this particular layer is the place where things will be slow. Introduce a single file or other 3rdparty IO dependent method on your HTTP response and poof
Re: Deno vs. Bun performance is rigged
#19Maybe it's just me, but there are some things I don't understand about this article.
> Deno is a multi-threaded server that utilizes in this test almost 2x the CPU-time while Bun is running single-threaded utilizing only 1x the CPU-time.
How do we know this? Also, when the author says that Deno is getting "almost 2x the CPU-time", does that mean Deno was being run on a 2-core machine?
> If we run the same test on a MacBook Air M1, with latest Bun v. latest Deno, we get the following:
What "same test" was run? The M1 MacBook Air has an 8-core CPU. If the "same test" means the test that the Deno people ran in the presentation, shouldn't Deno still be beating Bun due to the multi-core advantage?
I'm very willing to believe everything in the article. But especially with the author requesting that we verify and think critically, it would be helpful to have more details.
Re: Deno vs. Bun performance is rigged
#20Earlier quoted context omitted.
I can’t find the tweet right now but I follow the developer on twitter and his rationale was essentially that he wanted to focus on nailing single core speeds before expanding to multi core. I assume this has to do with how extremely experimental bun is at the moment anyway. So they are focusing on nailing the fundamentals before attempting anything that would make it „production ready“ such as multi core support.
Ah yeah in the submitted article they say the updated benchmark used “ latest Bun…” - so does that mean that it was just tested using a released version (lacking multithreading) instead of a nightly build (with recently added multithreading)? As an aside, I’ve now seen a couple of HN submissions relating to Bun and there’s been a vibe that there’s conspiracy or foul play afoot in each. That’s a little … unusual. What…
No post body was provided.