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

111–120 of 196 posts

Re: Deno vs. Bun performance is rigged

#111

Post by nazka »

bornfreddy wrote: post #25
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…

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…

I agree. PReact for instance comes to my mind. But it’s faster! And? And is it really in a business web app and not just a printf(« hello world »)? Does it matter that much? Do they have as many dev working on it? What about edge cases? More than anything for this type of change does your faster magic new thing has even an ecosystem?

Re: Deno vs. Bun performance is rigged

#112

Post by pier25 »

swyx wrote: post #43
pier25 wrote: post #10

Earlier quoted context omitted.

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.

got a source for this stackoverflow peak? also wondering what peak RPS is for HN. i feel like most (non consumer) startups would be like "ok if its good enough for HN its good enough for me"

Their director of engineering did a podcast a couple of months ago:

https://hanselminutes.com/847/engineering-stack-overflow-wit...

Re: Deno vs. Bun performance is rigged

#113

Post by jesse__ »

jpgvm wrote: post #67
lucasyvas wrote: post #32

If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with other parts of your stack. As long as they are the same overall performance class, it doesn't matter.

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…

Completely agree.

I use C and C++ on a day to day basis, which has an extremely bad rap in the DX department. Even coming from languages that, by and large, have very poor DX, I find the JS and TS ecosystems to be intolerable. The tooling is extremely slow, buggy, and often produces straight-up incorrect results.

Re: Deno vs. Bun performance is rigged

#114

Post by rtorr »

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…

There is plans for multi core in the future already. They (bun) just aren’t there yet.

Re: Deno vs. Bun performance is rigged

#115

Post by hinkley »

jddil wrote: post #82
Jarred wrote: post #39

Earlier quoted context omitted.

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

Here’s another perspective on this: someday, you’re going to find bugs that require more code to work correctly, and more code is slower. If you’ve fixated on performance you now have a conflict of interest, and conflicts make it easier to talk yourself into bad solutions.

I say this as someone who has gotten a lot of pushback in my career about performance work. Performance is a thing that needs to be priority. It doesn’t trump all else.

Make it work, make it right, make it fast. When people skip step 2 (and a godawful number of people do) they make enemies of themselves to their coworkers.

Re: Deno vs. Bun performance is rigged

#116

Post by KronisLV »

orangepurple wrote: post #106
KronisLV wrote: post #100

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…

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

Read requests, sure. In that particular instance, I was testing a write heavy workload for my Master's Degree with K6 at the time: https://k6.io/

The idea was to see how performance intensive COVID contact tracking would be, if GPS positions were to be sent by all of the devices using an app, which would later allow generating heat maps from this data, instead of just contact tracing. Of course, I talked about the privacy implications of this as well (the repository was called "COVID 1984"), but it was a nice exercise to demonstrate horizontal scaling, the benefits of containerization and to compare the overhead of Docker Swarm with lightweight Kubernetes (K3s).

So yes, write heavy workloads are viable with Ruby on limited hardware, read heavy workloads can be even more easy (depending on who can access what data).

Re: Deno vs. Bun performance is rigged

#117

Post by RunSet »

gruez wrote: post #86
RunSet wrote: 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 r…

I'm not surprised that engines that prioritize "fresh" results only turn up claims that the most recent version of Windows is the fastest. Even so the most recent version does have higher system requirements than its predecessor.

Also your search fu is weak. Try: "Windows new version" faster old version

Windows 11 faster than Windows 10:

https://www.tomshardware.com/news/microsoft-details-how-it-m...

Windows 10 faster than Windows 8:

https://edu.gcfglobal.org/en/windows10/windows-10-features/1...

Windows 7 faster than Windows Vista:

https://www.lifewire.com/ways-windows-7-beats-windows-vista-...

To be clear I don't doubt that the claims are technically true. Lies by omission are often technically true.

Re: Deno vs. Bun performance is rigged

#118

Post by alpaca128 »

Meanwhile the author does the same omission of important details that Deno is being criticized for: the M1 has 8 cores, yet there's no mention about how those are used in the Deno vs. Bun benchmark. Did Deno only run on one core? Did they run 8 Bun instances in parallel? Who knows.

Re: Deno vs. Bun performance is rigged

#119

Post by acdha »

liuliu wrote: post #83
acdha wrote: post #62

Earlier quoted context omitted.

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.

I’m not saying it can’t happen, just that it’s pretty rare. SSDs are not infinite capacity and 100G networking isn’t common even in data centers - and more to the point, what really matters is latency: how many cycles can your CPU exercise in the time it takes for a round-trip network request is usually orders of magnitude greater than your business logic.

Again, not saying it never happens but I’ve rarely seen the kind of microbenchmark this story is about end up correlating with real application performance. I have seen developers get all fired up in some religious war and endanger their entire project trying to see benefits which never materialized, though, a common feature there was this focus on toy benchmarks rather than measuring the whole system or what they could do at the app level if they weren’t supporting some niche framework.

Re: Deno vs. Bun performance is rigged

#120

Post by kazinator »

"We interrupt the presentation of our project to bring you this important message about the existence of a similar project that we are afraid of, but think we beat on some benchmark of limited relevance. Having said that, please don't look up that project, let alone use it! ... We now return you to the presentation of our project."
Post reply on HN