Live data from Hacker News

Deno vs. Bun performance is rigged

unetworkingab.medium.com

21–30 of 196 posts

Re: Deno vs. Bun performance is rigged

#21
post #15
post #8

Earlier 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…

> 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. Kinda weird IMO

That's inevitable when companies with big investments have to market a performance-oriented product to a public that doesn't fully understand the nuance of software performance running on modern hardware.

The average JS dev doesn't really know what's happening behind the scenes, so a precise message will not be nearly as effective as slapping together a long and a short bar in a barchart. And since this type of marketing is imprecise by nature, tweaking some details lets opposing parties corroborate conflicting claims.

I've been through this same phenomenon when working at Redis Labs. Everybody had the fastest cache and/or db. Both Redis Labs and each of its competitors. You just had to pick the right bar chart.

Re: Deno vs. Bun performance is rigged

#22

It seems like there is some battle between the two with an article bashing Bun's performance metrics by a Deno contributor just the other day. The article doesn't do nearly as good of a job pointing out the differences though and the allegations by the Deno contributor which appear to be legitimate. Also, just because Bun is single threaded doesn't mean they should get special exceptions in performance testing. If th…

> Also, just because Bun is single threaded doesn't mean they should get special exceptions in performance testing.

Maybe the chart should point that out, if that's the case. Or maybe the person running the benchmark should run more than one instance of Bun to make it an apples-to-apples comparison.

Re: Deno vs. Bun performance is rigged

#23

This post doesn’t link to the original benchmark, or any code to verify what’s being suggested. Along with the click-bate heading, I think it’s fairly irrelevant. My assumption is that this is a micro benchmark doing just an echo response, that is so far from what Bun/Deno/Node will ever be used for it’s just a farce. The speed of your application frameworks http server will (almost) never be your bottleneck. Develop…

>This post doesn’t link to the original benchmark

Searching Google for the exact text in the slide doesn't yield any results. So perhaps that was part of the post author's angst...that the numbers were presented in a venue where they wouldn't get much scrutiny?

Edit: I did find that the author has posted previously about Deno, and seems to not be a fan: https://unetworkingab.medium.com/deno-is-slow-and-why-associ...

Re: Deno vs. Bun performance is rigged

#25

Im 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…

You'd be surprised. I've had countless battles with (junior-wannabe-senior) devs who wanted to use a different framework simply because it is "fast". When you point out that this project will be a huge success if it has 10 req/s, the usual answer is "well it doesn't hurt", when it truth it does - if nothing else, because it diverts discussion from important matters (like consistency of the company's tech stack) to irrelevant ones.

Dino makers are well aware of this. An otherwise great Python framework (based on Starlette) is even named "FastAPI" in an attempt to use this to their advantage (it is great for other reasons, not because of its speed).

Unfortunately lots of devs are looking for silver bullets when it comes to speed, instead of detecting, determining, investigating and removing the bottlenecks.

Re: Deno vs. Bun performance is rigged

#26
post #23

This post doesn’t link to the original benchmark, or any code to verify what’s being suggested. Along with the click-bate heading, I think it’s fairly irrelevant. My assumption is that this is a micro benchmark doing just an echo response, that is so far from what Bun/Deno/Node will ever be used for it’s just a farce. The speed of your application frameworks http server will (almost) never be your bottleneck. Develop…

>This post doesn’t link to the original benchmark Searching Google for the exact text in the slide doesn't yield any results. So perhaps that was part of the post author's angst...that the numbers were presented in a venue where they wouldn't get much scrutiny? Edit: I did find that the author has posted previously about Deno, and seems to not be a fan: https://unetworkingab.medium.com/deno-is-slow-and-why-associ...

I did the same before posting my comment, I wanted to check what actually was going on.

> that the numbers were presented in a venue where they wouldn't get much scrutiny?

The OP has done the same though by not linking to or explaining the context. Or showing the code.

Re: Deno vs. Bun performance is rigged

#27
post #13
post #7

Earlier quoted context omitted.

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.

It's been 14 years since the v8 engine was released. Node.js has been out longer than 10 years.

Re: Deno vs. Bun performance is rigged

#28
post #2

Why isn’t bun utilising multiple cores?

I think it’s better to do it via multiple JS VMs than one http server splitting the work between multiple threads. There’s really not enough work for it to be worthwhile otherwise

Bun will eventually implement Worker/worker_threads and that will have an integration with the HTTP server for load balancing

Re: Deno vs. Bun performance is rigged

#29
I've been a little puzzled about the latest runtime competition. Bun is a great package manager but I don't see why you'd choose it as a runtime. Ditto with Deno and whatever other runtimes have entered the competition. Seems like you'd start using one, realize npm compatibility is rather poor, and pick the runtime that actually lets you, yknow, do stuff, i.e. node.

Re: Deno vs. Bun performance is rigged

#30

And the original benchmarks of bun vs deno had bun using a native-code http server against a deno using a js-code http server, afaik. And the bun-specific-fork-of-react vs deno + normal react, was suspect too.

When you import “react-dom/server” in Node, it actually loads “react-dom/server.node.js”

When you import “react-dom/server” in browsers or Deno, it loads “react-dom/server.browser.js”

When you import “react-dom/server” in Bun, it will load “react-dom/server.bun.js”.

https://twitter.com/sebmarkbage/status/1560609478227030016

Post reply on HN