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.
Deno vs. Bun performance is rigged
101–110 of 196 posts
Re: Deno vs. Bun performance is rigged
#102Earlier 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.
Re: Deno vs. Bun performance is rigged
#103Earlier 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.
[0] https://www.techempower.com/benchmarks/#section=data-r21
Re: Deno vs. Bun performance is rigged
#104Im 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…
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
#105Earlier 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"]) ?
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.)
Re: Deno vs. Bun performance is rigged
#106Earlier 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…
Re: Deno vs. Bun performance is rigged
#107Maybe 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…
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> 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.
There are definitely benefits of using multiple cores at once on a single app.
Re: Deno vs. Bun performance is rigged
#109Earlier 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.
Re: Deno vs. Bun performance is rigged
#110Earlier 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.