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

151–160 of 196 posts

Re: Deno vs. Bun performance is rigged

#151

Post by xaduha »

maccard wrote: post #138
LunaSea wrote: post #134

Earlier quoted context omitted.

JavaScript is ranked 5th on the ranking you linked to. 4 ranks before .Net.

I was hesitant as to how much I should go into this because you get into the semantics of the benchmark but this [0] thread goes into why - that particular implementation doesn't behave the same way as the other implementations, it uses a different db driver that doesn't synchronise, which won't be allowed in the next version of the benchmarks. Techempower publish regular snapshots of their benchmarks at [1], and if…

Are you sure about your conclusion though? Apart from just-js missing in action in last 3 runs, here it's just fine

https://www.techempower.com/benchmarks/#section=test&runid=e...

Re: Deno vs. Bun performance is rigged

#152

Post by eyelidlessness »

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…

This microbenchmark in particular isn’t a reason I’d consider Bun. But the sum of many performance and DX considerations that have been put into Bun’s development—and that they are core motivating principles for the creator—certainly are.

As for the error, I suspect it was an innocent mistake. I see no reason Deno would choose to mislead, when they’ve generally very publicly responded to performance deficits by acknowledging them and then actually improving real performance.

Re: Deno vs. Bun performance is rigged

#153

Post by ok_dad »

phillipcarter wrote: post #125
coder543 wrote: post #105

Earlier quoted context omitted.

That's not what anyone is talking about. Take this example from their docs: @app.get("/items/{item_id}") async def read_item(item_id: int, q: Union[str, None] = None): return {"item_id": item_id, "q": q} You are declaring the types of the parameters, and FastAPI parses and enforces them for you. This saves quite a bit of code, and lets you focus on your business logic. Writing the code this way also allows FastAPI to…

Properly supporting async seems like the main reason why it's taken off.

I assure you, a large part of using fastapi for my company was the integration with pydantic for easy validation.

Re: Deno vs. Bun performance is rigged

#154

Post by postalrat »

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

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

You would think by now that SQL databases would be pretty good about optimizing any query it receives.

Re: Deno vs. Bun performance is rigged

#155

Post by squeaky-clean »

andirk wrote: post #109
kitd wrote: post #49

Earlier quoted context omitted.

Ikr. You can regularly read some random dev tell the world "interpreted" Java is "too slow" for them.

Javascript isn't Java. Javascript follows ECMAScript, which also isn't Java. And ECMAScript isn't a language.

I don't know if they were making a JS joke but I have legitimately had newer programmers tell me that Java is an interpreted language because it compiles to a bytecode language which is interpreted by the JVM. Inversely I've had people argue that JS and Python are compiled languages because their interpreters convert statements into bytecode before executing them. When someone starts trying to argue those points I find its best to just give them a thumbs up and leave the conversation.

Re: Deno vs. Bun performance is rigged

#156

Post by papito »

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…

In a world where engineers just keep piling on cloud toys and oh hey microservices to solve very common problems, pretending that database and HTTP roundtrips are basically free, your choice of framework and language should not even matter. This is what's wrong with this industry.

Re: Deno vs. Bun performance is rigged

#157

Post by squeaky-clean »

simpsond wrote: post #142
m00x wrote: post #108

Earlier quoted context omitted.

But then you need twice the initial app memory. This can be substantial for larger apps. There are definitely benefits of using multiple cores at once on a single app.

Copy on write fork mitigates some of that.

There was a recent post about a new Ruby server implementation. The author pointed out that for interpreted languages, forking quickly deviates and gains very little benefit from copy-on-write. However! Pre-warming the first instance and then forking afterwards brought the memory savings back down to compiled levels. No real point to my comment except that it was new knowledge to me, and that efficiency of forking really depends on the implementation of what/when you're forking.

Re: Deno vs. Bun performance is rigged

#158

Post by christophilus »

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

Youre almost proving my point. This bechmark is focused on one tiny layer. It’s not executing complex graph queries. If you want to do a real comparison then the benchmark should be “apollo graph query performance on node vs deno vs bun” and then decide if its good enough to compare speed of feature delivery using knex. Even then the benchmark would need to be carefully crafted.

Hot take: If every layer of your stack focused on similarly useless performance improvements, the web would be a much better place.

Re: Deno vs. Bun performance is rigged

#159

Post by kaba0 »

locutous wrote: post #150
maccard wrote: post #103

Earlier quoted context omitted.

I'm afraid it was a while back so I don't have it to hand, but what I do have is the techempower benchmarks [0] which show about a 10x difference between asp.net or go, and all of the js options. I'm not going to claim they're perfect, and would be happy if you could provide some info that supports your argument? [0] https://www.techempower.com/benchmarks/#section=data-r21

And yet the top js entry is above all c# and go entries. It takes the top overall on the composite score. Not that it is representative of actual use cases. Can't use just-js in production as it's hyper optimized for this benchmark rather than a work horse. But it does provide a better view of what is possible if the work is put in.

Isn’t that just basically a js wrapper over a very optimized c++ lib though?

Re: Deno vs. Bun performance is rigged

#160

Post by spyder »

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…

Here is a more realistic benchmark:

https://dev.to/builderio/a-first-look-at-bun-is-it-really-3x...

Post reply on HN