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

31–40 of 196 posts

Re: Deno vs. Bun performance is rigged

#31

Post by maccard »

ex3ndr wrote: post #7
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…

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.

> Javascript is plagued with idea that it is slow while it is not.

I benchmarked a hello world in .net and node/express, and the .net version was multiple orders of magnitude faster than the node/express version. That's a starting point, and as you add more logic, that gap only grows in my experience. Javascript may be fast _enough_ for many cases, and in a tight JIT loop it may be faster again, but by any measure, js is not quick.

Re: Deno vs. Bun performance is rigged

#32

Post by lucasyvas »

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.

Re: Deno vs. Bun performance is rigged

#33

Post by nesarkvechnep »

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…

Bet they, the junior devs, can’t even optimise their SQL queries.

Re: Deno vs. Bun performance is rigged

#34

Post by jddil »

Not rigged at all. Just a joke of a microbenchmark trying to equate a toy with an actual runtime.

Bun may be great someday, but right now it’s missing such basic functionality that any benchmark is a farce. Nobody cares that you can quickly ack a request a half million times a sec if you can’t do something as basic as spawn a child process.

Re: Deno vs. Bun performance is rigged

#35

Post by PedroBatista »

Micro and synthetic benchmarks are useful, however people tend to attribute WAY too much importance to them because it quickly becomes a battle of egos IMO.

It's entertaining seeing these 2 camps throwing jelly at each other, it's healthy to a point and when it stops being healthy by that time most have moved on to the new shinny thing.

I suspect since both have taken investor money, that is a factor too.

Re: Deno vs. Bun performance is rigged

#36

Post by QuiiBz »

GavinAnderegg wrote: post #19

Maybe 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 M…

> How do we know this?

Looking at the source code [0] for Deno HTTP server, they spawn at least one thread for the server to listen and handle requests, before they are sent through a MPSC channel to the thread running the Isolate.

[0]: https://github.com/denoland/deno/blob/07213dec94398aab687afd...

Re: Deno vs. Bun performance is rigged

#37

Post by geysersam »

maccard wrote: post #31
ex3ndr wrote: 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.

> Javascript is plagued with idea that it is slow while it is not. I benchmarked a hello world in .net and node/express, and the .net version was multiple orders of magnitude faster than the node/express version. That's a starting point, and as you add more logic, that gap only grows in my experience. Javascript may be fast _enough_ for many cases, and in a tight JIT loop it may be faster again, but by any measure, j…

No realistic, decently written, js application would be "orders of magnitude" faster if rewritten in .net.

Re: Deno vs. Bun performance is rigged

#38

Post by lillecarl »

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…

I've thought of the fastapi name as that it's fast to get going with rather than speed, it's python after all.

Re: Deno vs. Bun performance is rigged

#39

Post by Jarred »

jddil wrote: post #34

Not rigged at all. Just a joke of a microbenchmark trying to equate a toy with an actual runtime. Bun may be great someday, but right now it’s missing such basic functionality that any benchmark is a farce. Nobody cares that you can quickly ack a request a half million times a sec if you can’t do something as basic as spawn a child process.

Spawning processes was added in Bun v0.2.0 (released three days ago). It internally uses posix_spawn. That being said, there’s definitely still a lot of work to do in Bun

Re: Deno vs. Bun performance is rigged

#40

Post by Ygg2 »

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.

DX? What's that?
Post reply on HN