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

171–180 of 196 posts

Re: Deno vs. Bun performance is rigged

#171

Post by locutous »

kaba0 wrote: post #159
locutous wrote: post #150

Earlier quoted context omitted.

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?

Might call node.js the same thing. Deno has a rust shell and bun is zig.

Just-js had spent a lot of resources optimizing the input and output gateways to the V8 engine and it obviously pays off nicely. It does serve requests with the JS.

Is the boundary in the same place? Not familiar enough with the others to say exactly. But does it really matter?

Re: Deno vs. Bun performance is rigged

#172

Post by toastercat »

leeoniya wrote: post #163
toastercat wrote: post #161

Earlier quoted context omitted.

Kinda devil's advocate, but I've met several senior-should-be-junior cargo-culting devs who swear by popular tools that are objectively slower than alternatives, instead of actually taking the time to evaluate the less popular alternatives to see if the lack of surrounding ecosystem will actually affect their project. The result is a death by a thousand cuts, because they auto-pilot to "what is everyone else using"?

> to see if the lack of surrounding ecosystem will actually affect their project for projects of any significant size, that answer is a resounding "yes".

I think engineering is more nuanced than that, personally.

Re: Deno vs. Bun performance is rigged

#173

Post by TobyTheDog123 »

rwalle wrote: post #144
jpgvm wrote: post #67

Earlier quoted context omitted.

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…

LOL I have done front end development for hobby and professionally for over a decade. I can confirm that this guy does not understand the history, limitation and complexity of tooling around the ecosystem and is just here being uninformed and whining. Phrases like "real compiler" tell enough about people who mostly work in the back end that do not understand how the real world works for web. Or let me ask this questi…

> I can confirm that this guy does not understand the history, limitation and complexity of tooling

It sounds like he does, at least a little bit, because that's the problem he has with it?

>Phrases like "real compiler" tell enough about people who mostly work in the back end that do not understand how the real world works for web.

"How the real world works for the web" is the problem.

>How would you change all this?

WebAssembly/WASI is a pretty good start IMO: Having a compiled language with escape hatches to browser APIs is the ideal for me. Personally, the closest I've seen is Flutter's Skia/CanvasKit (which does use WASM, apparently). I'd certainly like to see applications of similar concepts in other languages/frameworks though.

Re: Deno vs. Bun performance is rigged

#174

Post by BiteCode_dev »

phillipcarter wrote: post #96
BiteCode_dev wrote: post #41

Earlier quoted context omitted.

That's my take on it as well. Fast apu does use asyncio which may have speed avantages in some circonstances. But the main takeaway and the killer feature is the fact you build your api just declaring functions signatures.

Is it really that big of a deal that you can do @app.post("/foo") instead of @app.route("/foo", methods=["POST"]) ?

It's not that. Fast API comes with a way to declare python types to get for free:

- URL params, forms and query string parsing and validation

- (de)serialization format choice

- dependency injection for complex data retrieval (this one is very underrated and yet is amazing for identification, authentication, session and so on)

- output consistency guarantees

- API doc generation

Re: Deno vs. Bun performance is rigged

#175

Post by koala_man »

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…

> Single core CPUs are few and far between those days.

I would not be surprised if it's more common to run on a single CPU machine today than 10 years ago due to cloud VM instances.

Re: Deno vs. Bun performance is rigged

#176

Post by geysersam »

jesse__ wrote: post #101
geysersam wrote: post #37

Earlier quoted context omitted.

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

Maybe not .net, but I've worked on 3D graphics in the browser and can say with confidance that rewriting your app in C or C++ could see orders of magnitude perf increase over JS.

Comparing a pure js implemention to code using opengl or webgl, I imagine several orders of magnitude difference is likely.

But a decent js implemention of 3D graphics-something would use one of the available tools for such applications. Making the difference considerably smaller.

Or is you experience different?

Re: Deno vs. Bun performance is rigged

#177

Post by Matthias247 »

The most problematic thing about the state of the world for web framework benchmarks is that some of them drop a lot of real world requirements while showcasing high RPS.

E.g. a signficant number of frameworks on the techempower benchmark don't run with any timeouts in the various stages of a HTTP request lifecycle. That would mean if one would deploy those in the real world the server would sooner or later run out of memory or fd's due to broken client connections. Once you add timeouts, performance would already drop.

Then there is logging and metrics, which are absolutely required for any production setup, but never included in any of those proof of concept setups.

If the performance after those mandatory things is added drops 2 to 4x, the conclusions from the benchmarks can be very different.

Re: Deno vs. Bun performance is rigged

#178

Post by billywhizz »

kaba0 wrote: post #159
locutous wrote: post #150

Earlier quoted context omitted.

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?

like bun or node or deno (Rust as well as C++).

in techempower, the vast vast majority of code running in the just-js entry is JavaScript. all the core libraries for networking and interacting with the OS are js wrappers around C++/v8. the http server, though incomplete and not production rady, is written in javascript, with http parsing handed off to picohttpparser. the postgres wire protocol is completely written in javascript. in fact, one of the advantages JS and other JIT languages have is you can optimize away a lot of unnecessary logic at run time when you need to. e.g. https://github.com/just-js/libs/blob/main/pg/pg.js#L241

the whole point of doing this was to prove that JS can be as fast as any other language for most real world web serving scenarios.

if i had more time to work on it, i am sure i could improve the fortunes score where it would be at or very close to the top of that ranking too.

Re: Deno vs. Bun performance is rigged

#179

Post by billywhizz »

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…

i'm sorry but this is not true. postgres pipelining is not allowed in the benchmarks any more, and even when it was, just-js was completely compliant with the rules and it was other C++, PHP, Rust and C# frameworks that were non compliant.

the postgres driver was rewritten in JS because i spent so long benchmarking using the pg C driver and couldn't get the performance i needed from it. if you actually read the github thread you can see i even did a lot of work to verify the various frameworks were compliant with the requirements.

in round 21, postgres pipelining was disallowed for all frameworks and just-js/JavaScript is in first place. \o/

https://www.techempower.com/benchmarks/#section=data-r21&hw=...

Re: Deno vs. Bun performance is rigged

#180

Post by billywhizz »

xaduha wrote: post #151
maccard wrote: post #138

Earlier quoted context omitted.

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...

they upgraded postgres recently and it uses a different default authentication mechanism which broke just-js. they seem to have stopped doing runs right now so just-js should re-appear when they start again.
Post reply on HN