Live data from Hacker News

Deno vs. Bun performance is rigged

unetworkingab.medium.com

101–110 of 196 posts

Re: Deno vs. Bun performance is rigged

#101
post #31

Earlier quoted context omitted.

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

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.

Re: Deno vs. Bun performance is rigged

#102
post #55

Earlier quoted context omitted.

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.

I appreciate that Bun wants to be fast, but what I need right now from Bun or Deno is a better concurrency primitive than sendMessage(). I’m so… angry that we waited all this time for a worker threads implementation in Node and what we got was this hot garbage. It’s a toy. There is no sane way to send multiple tasks to the same worker, because the results come back unordered and uncorrelated, unless you build your own layer on top of them. The public API should have been promise based, not event based.

Re: Deno vs. Bun performance is rigged

#103
post #59
post #31

Earlier quoted context omitted.

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

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

Re: Deno vs. Bun performance is rigged

#104

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 is so true.

Developers should focus more about time spent getting an application up and running (and to market) rather than how much time is spent serving an http request.

Re: Deno vs. Bun performance is rigged

#105

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"]) ?

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 generate a meaningful description of your API, which can be schema (such as Swagger) that tools can use to generate clients, or it can be documentation pages for humans to read. Any good documentation will still require you to write things, but this gets you further, faster than using something like Flask.

This example[0] takes these concepts even further.

Or just glance at the summary and see that it has nothing to do with @app.post.[1]

FastAPI has also properly supported async routes for longer than Flask, from what I understand.

(I've never personally used FastAPI for anything serious, since I have rarely used Python for anything other than machine learning for the past 5+ years, preferring to use Go, Rust, or TypeScript for most things, but I am aware of it, and seeing its claims misrepresented like that is mildly annoying. FastAPI is far more appealing to me than any other Python web framework I've ever seen, and I've only heard good things about it. Based on my experiences in other languages, their approach to writing APIs is absolutely a good one.)

[0]: https://fastapi.tiangolo.com/#example-upgrade

[1]: https://fastapi.tiangolo.com/#recap

Re: Deno vs. Bun performance is rigged

#106

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…

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

If you cache correctly I think 200 requests per second comes out to something like tens of thousands of active users

Re: Deno vs. Bun performance is rigged

#107

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…

Thermal throttling is going to be part of this mix. Especially on an Air. I can’t even run useful benchmarks on my work laptop. I get purely random results every time. I gave up and created benchmarks I can run in CI.

So the logical fallacy here is that since the Bun version is leaving more cores idle that we can run more copies to get even more throughput. Yes, but actually no. You’ll get more throughput, but not at the multiple you think. The real test of a system is when you redline it for all scenarios.

Re: Deno vs. Bun performance is rigged

#108
post #71
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.

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.

Re: Deno vs. Bun performance is rigged

#109
post #49
post #13

Earlier quoted context omitted.

To be fair it did used to be quite slow. But that was like 10 years ago. General awareness hasn't caught up to the huge engineering efforts it seems.

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.

Re: Deno vs. Bun performance is rigged

#110
post #77
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…

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.

They may be the worst, but they have now become extremely common to find in a variety of company projects. Not just FAANG or FAANG-adjacent but boring insurance or healthcare companies too.
Post reply on HN