Deno vs. Bun performance is rigged • Hacker News Board

Re: Deno vs. Bun performance is rigged

#51

Post by redox99 » Sun, Oct 16, 2022, 2:03 PM UTC

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 the CSS-in-JS. The server rendering the page can easily take 200ms or more.

2) Modern backend stacks. On an API I have I use Prisma + Apollo GraphQL. Some queries take 500ms. These same queries but using REST and knex are In either case, the user experience is impacted because the website becomes slower. And a faster runtime would make these JS run faster, thus the web/api load faster.

Re: Deno vs. Bun performance is rigged

#52

Post by duxup » Sun, Oct 16, 2022, 2:04 PM UTC

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…

It doesn’t help that many tools, frameworks and etc advertise these kinds of numbers.

I find the reason for using a tool often isn’t what they list first in their technical documentation.

I can understand why someone might think those really are the reasons to use that tool.

Re: Deno vs. Bun performance is rigged

#53

Post by thinkingkong » Sun, Oct 16, 2022, 2:04 PM UTC

kotlin2 wrote: post #42

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…

But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.

Its tempting to assume that just because this number is high, that the rest of the dependencies required to meaningfully respond will be equally performant. That is rarely the case.

The challenge I have with these positions is that unless you have very specific latency requirements, most of the time youre better off focusing on solving a business problem and then measuring what is slow. Starting off with “well it has to be fast so lets use this brand new thing” is the swan song of the eventually remorseful.

Re: Deno vs. Bun performance is rigged

#54

Post by eddyg » Sun, Oct 16, 2022, 2:05 PM UTC

Related flagged article with good context/comments that a lot of HN readers probably didn't see because it got flagged:

https://news.ycombinator.com/item?id=33199351

Re: Deno vs. Bun performance is rigged

#55

Post by kotlin2 » Sun, Oct 16, 2022, 2:06 PM UTC

thinkingkong wrote: post #53

kotlin2 wrote: post #42

Earlier quoted context omitted.

But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.

Its tempting to assume that just because this number is high, that the rest of the dependencies required to meaningfully respond will be equally performant. That is rarely the case. The challenge I have with these positions is that unless you have very specific latency requirements, most of the time youre better off focusing on solving a business problem and then measuring what is slow. Starting off with “well it has…

Bun has a philosophy that everything needs to be fast. Including things like CLI tools and process startup. Process startup being quick is important, especially in a severless environment. I understand your point, but it’d be nice to limit the discussion to Bun and Deno and not other theoretical possibilities.

Re: Deno vs. Bun performance is rigged

#56

Post by Jenk » Sun, Oct 16, 2022, 2:07 PM UTC

kotlin2 wrote: post #42

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…

But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.

> But all else equal

This is the point GP is making - they (the "junior-wannabe-senior") aren't even thinking of all else, and by focussing purely on the speed of operations are probably using the lesser optimal solution. Facetious example: A is faster than B, shaving a few cycles here and there. But nobody knows how to use A, it's support is lacklustre, and there are many known vulnerabilities that haven't been fixed. B is the most widely used in the industry, support and security is good. Junior-wannabe-senior is picking A because it's faster.

Re: Deno vs. Bun performance is rigged

#57

Post by onionisafruit » Sun, Oct 16, 2022, 2:10 PM UTC

kristoff_it wrote: post #21

smcl wrote: post #15

Earlier quoted context omitted.

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

I recently took a deep dive into competing json packages for go. They all have charts showing they are the fastest. Some just leave out faster packages (often because the readme is from before the faster packages existed), but others seem to have conflicting claims. When you look at them in detail, it’s often because they don’t understand what the other packages are doing (maybe willfully misunderstanding). So they end up comparing their package validating the json with another package validating the json and copying the values in memory.

Re: Deno vs. Bun performance is rigged

#58

Post by bornfreddy » Sun, Oct 16, 2022, 2:12 PM UTC

lillecarl wrote: post #38

bornfreddy wrote: post #25

Earlier quoted context omitted.

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.

Maybe - in that case I'm judging them wrongly. But flask (the king they dethroned) was faster to get going (with less features, granted) and their docs feature "Performance" [0] rather prominently.

Note that I don't hold this against them. They simply understand what makes the devs pick them and adjusted their market strategy accordingly. It would be nice if they didn't have to though.

[0] https://fastapi.tiangolo.com/#performance

Re: Deno vs. Bun performance is rigged

#59

Post by kaba0 » Sun, Oct 16, 2022, 2:13 PM UTC

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…

I’m sorry, but I simply don’t buy that. You either measured something unrelated (e.g. framework), or it was a faulty benchmark for some other reason.

Re: Deno vs. Bun performance is rigged

#60

Post by netheril96 » Sun, Oct 16, 2022, 2:14 PM UTC

thinkingkong wrote: post #53

kotlin2 wrote: post #42

Earlier quoted context omitted.

But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.

Its tempting to assume that just because this number is high, that the rest of the dependencies required to meaningfully respond will be equally performant. That is rarely the case. The challenge I have with these positions is that unless you have very specific latency requirements, most of the time youre better off focusing on solving a business problem and then measuring what is slow. Starting off with “well it has…

But if the problem is in the framework or the runtime, it is too late to think about the performance AFTER you have tied yourself all up to the slower one.