Live data from Hacker News

Deno vs. Bun performance is rigged

unetworkingab.medium.com

81–90 of 196 posts

Re: Deno vs. Bun performance is rigged

#81
Reminds me of how each version of Windows is "the fastest Windows ever!" while the minimum system requirements increase with each version of Windows.

However do the geniuses at Microsoft manage to make Windows run faster while only requiring faster hardware?

Re: Deno vs. Bun performance is rigged

#82
post #39
post #34

Not rigged at all. Just a joke of a microbenchmark trying to equate a toy with an actual runtime. Bun may be great someday, but right now it’s missing such basic functionality that any benchmark is a farce. Nobody cares that you can quickly ack a request a half million times a sec if you can’t do something as basic as spawn a child process.

Spawning processes was added in Bun v0.2.0 (released three days ago). It internally uses posix_spawn. That being said, there’s definitely still a lot of work to do in Bun

Fair enough and you seem to be adding features fairly quick which is impressive to watch, but my point still stands.

These benchmarks don't make me think Bun is fast, they make me think Bun is cheating in something they don't need to cheat in yet.

Go heads down, finish adding features, run another benchmark when you're closer to parity and promote THAT heavily. Sure it won't be such a dramatic difference once you have to compare apples to apples but it'll be more honest.

Re: Deno vs. Bun performance is rigged

#83
post #62
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…

You’re not wrong but I do think it’s important to remember the context: people don’t tend to write math-heavy code in classic JS (there’s a side discussion about WASM now) so relatively few apps bottleneck on CPU - it’s wild when you see people going on about how they need to switch frameworks based on some microbenchmark of request decoding when 99% of their request processing time is some kind of database. I’ve see…

"Relatively few apps bottleneck on CPU" is a very 2010 opinion. With fast intranet (100Gbps+) and SSD, running business logic can become the bottleneck in many cases.

Unfortunately, I don't have readily available data to back up my claim neither.

Re: Deno vs. Bun performance is rigged

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

Agreed. But the problem is not on "fast" but on "brand new". Sometimes, these are equal (because new things often advertising itself as fast alternative). Rare times when this is not equal, fast can be a good choice.

Re: Deno vs. Bun performance is rigged

#85

I'm surprised to read that "Bun actually sits above a URL router capable of matching methods, URL wildcards and parameters". I thought bun was just a JS runtime, though I guess thinking about it maybe I don't even understand what a JS runtime is . I always figured nodejs is v8 + an stdlib. I think bun is a custom zig-js engine + an extended stdlib (website claims "batteries included")? Isn't the router generally "app…

V8 only provides javascript execution. All the browser APIs need to be implemented by runtime such as fetch, filesystem, console, http, Intl, webgpu, serialization, any global objects, cloning, message passing, etc.

Any module system and dependency management is part of runtime (loading scripts, running them before executing code, etc).

Any other execution context such as workers or running wasm is also responsibility of runtime to implement and manage.

FFI or native extensions are also part of runtime. So one may use the built in networking APIs to build a server framework such as express or they may opt to bring their own networking layer through a native extension.

Frameworks such as express and next build on top of http node module.

Many of these APIs provided by runtime are also simply js scripts run in the global context before running your code.

Router is application specific, not part of any of the JS runtime but URL pattern can be used to build a router which is a standardized API implemented by both browsers and deno.

Runtime can choose to provide any API they want under their namespace so deno could provide a full blown router if they want to.

Does that clear it up?

Re: Deno vs. Bun performance is rigged

#86
post #81

Reminds me of how each version of Windows is "the fastest Windows ever!" while the minimum system requirements increase with each version of Windows. However do the geniuses at Microsoft manage to make Windows run faster while only requiring faster hardware?

>Reminds me of how each version of Windows is "the fastest Windows ever!"

Says who? I searched for "windows 10 fastest" and the only relevant results were:

* claims about edge being faster, which is probably true given how much work they put into optimizing it for windows

* third party reviews saying that windows 10 S was faster (than home/pro), which is probably also true because it's so locked down that you can't run anything that slows it down

Re: Deno vs. Bun performance is rigged

#87
post #51

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…

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.

Re: Deno vs. Bun performance is rigged

#88
post #10

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…

Exactly. Very few companies will need to reach 1000 reqs/s consistently, let alone 100k reqs/s. StackOverflow peaks at about 6000 reqs/s and it's an extremely popular website.

Except low concurrency is often found alongside slow response time.

Re: Deno vs. Bun performance is rigged

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

[deleted]
Post reply on HN