Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno vs. Bun performance is rigged

unetworkingab.medium.com

Post reply on HN
Print view View original

71–80 of 196 posts

Re: Deno vs. Bun performance is rigged

#71

Post by detaro »

zamalek wrote: post #68

> 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. So we should intentionally handicap Deno? This is complete nonsense. If Bun wants to come out ahead of Deno, then they should also consider scaling with the number of CPU cores. Single core CPUs are few and far between those days. Real-world performance is what matte…

And a real-world deployment of a single-threaded interpreter just runs multiple instances of it, so do and compare that. No need to "handicap" anything.

Re: Deno vs. Bun performance is rigged

#72

Post by lucasyvas »

jpgvm wrote: post #67
lucasyvas wrote: post #32

If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with other parts of your stack. As long as they are the same overall performance class, it doesn't matter.

If you are buying into JS/TS the very last thing you are getting is DX. I have never worked with such a low quality ecosystem ever before and I hope I won't have to endure it for too much longer. If you want DX you are better off with JVM, Rust or something similarly well designed. Hell, Go has better DX than JS/TS and that is a pretty low bar. Real build systems, real module systems (instead of like 3 competing inco…

You are free to think that - I personally don't think you give it enough credit, but if your general argument is that there's a best tool for the job and this isn't it, I would agree within the context of this topic: performance.

Deno is objectively a pretty nice package and does a better job than its JS predecessors of delivering on DX. But my fear is that JS is inherently fragmented and this will never be truly resolved. I personally wouldn't dissuade those from using it - you can still achieve great results. But it's not a poster child for how we should do things. That undertone bothers me a lot more than the runtimes themselves.

Re: Deno vs. Bun performance is rigged

#73

Post by __alexs »

redox99 wrote: post #51
thinkingkong wrote: post #5

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…

I disagree. If we're talking of microbenchmarks focused on 100k rps or whatever that are mostly IO/syscall limited, sure. But if it's that JS execution is outright faster, it's a big deal. People here handwave "oh, your business doesn't require more than 10rps". Sure. But rps is just half the story, latency is the other. I'll give you two examples 1) SSR with something like Material UI is slow , especially because of…

They are all V8 so will all be approximately the same speed of JS execution I imagine?

Re: Deno vs. Bun performance is rigged

#74

Post by [deleted] »

zamalek wrote: post #68

> 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. So we should intentionally handicap Deno? This is complete nonsense. If Bun wants to come out ahead of Deno, then they should also consider scaling with the number of CPU cores. Single core CPUs are few and far between those days. Real-world performance is what matte…

[deleted]

Re: Deno vs. Bun performance is rigged

#75

Post by detaro »

__alexs wrote: post #73
redox99 wrote: post #51

Earlier quoted context omitted.

I disagree. If we're talking of microbenchmarks focused on 100k rps or whatever that are mostly IO/syscall limited, sure. But if it's that JS execution is outright faster, it's a big deal. People here handwave "oh, your business doesn't require more than 10rps". Sure. But rps is just half the story, latency is the other. I'll give you two examples 1) SSR with something like Material UI is slow , especially because of…

They are all V8 so will all be approximately the same speed of JS execution I imagine?

They are not all V8

Re: Deno vs. Bun performance is rigged

#76

Post by Waterluvian »

bornfreddy wrote: post #25
thinkingkong wrote: post #5

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

The last sentence kind of contradicts the preceding ones.

I agree that it’s harmful to distract from what actually matters: the core goal and competencies of the team.

But therefore we should hope devs look for silver bullets to address performance without having to be distracted by it. “It’s out of the box pretty good so I don’t have to think about caching or CDNs or load balancing until later” is deeply valuable.

Re: Deno vs. Bun performance is rigged

#77

Post by weego »

redox99 wrote: post #51
thinkingkong wrote: post #5

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…

I disagree. If we're talking of microbenchmarks focused on 100k rps or whatever that are mostly IO/syscall limited, sure. But if it's that JS execution is outright faster, it's a big deal. People here handwave "oh, your business doesn't require more than 10rps". Sure. But rps is just half the story, latency is the other. I'll give you two examples 1) SSR with something like Material UI is slow , especially because of…

You've given 2 of the worst (imo) regressions in frontend dev in the last decade.

If you're relying on innovation to make your existing tech stack not behave like dogshit when proven and trivial solutions exist, you're valuing the wrong things when choosing your stack.

Re: Deno vs. Bun performance is rigged

#78

Post by searchableguy »

__alexs wrote: post #73
redox99 wrote: post #51

Earlier quoted context omitted.

I disagree. If we're talking of microbenchmarks focused on 100k rps or whatever that are mostly IO/syscall limited, sure. But if it's that JS execution is outright faster, it's a big deal. People here handwave "oh, your business doesn't require more than 10rps". Sure. But rps is just half the story, latency is the other. I'll give you two examples 1) SSR with something like Material UI is slow , especially because of…

They are all V8 so will all be approximately the same speed of JS execution I imagine?

Bun uses javascript core.

There is also overhead in passing structures and other communication required so that layer can change the number as well.

Re: Deno vs. Bun performance is rigged

#79

Post by zamalek »

detaro wrote: post #71
zamalek wrote: post #68

> 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. So we should intentionally handicap Deno? This is complete nonsense. If Bun wants to come out ahead of Deno, then they should also consider scaling with the number of CPU cores. Single core CPUs are few and far between those days. Real-world performance is what matte…

And a real-world deployment of a single-threaded interpreter just runs multiple instances of it, so do and compare that. No need to "handicap" anything.

My gut would say that you're paying 2x the overhead for a JS runtime. Of course, such a benchmark (edit: N instances of Bun and N instances of Deno) would be much more realistic/relevant.

Re: Deno vs. Bun performance is rigged

#80

Post by [deleted] »

zamalek wrote: post #68

> 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. So we should intentionally handicap Deno? This is complete nonsense. If Bun wants to come out ahead of Deno, then they should also consider scaling with the number of CPU cores. Single core CPUs are few and far between those days. Real-world performance is what matte…

[deleted]
Post reply on HN