Deno v. Bun performance is rigged

It’s easy to win with twice the disposable computing power as your adversary

Presented below, by the Deno crew, is the claim that Deno outruns up and coming Bun when it comes to HTTP. There’s a small win for Deno presented, with Bun right after:

Now, even if we take the numbers given and swallow them whole, there’s an awfully important detail omitted; 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.

In other words; Bun is run on 1 CPU while Deno is run on 2 CPUs here.

This is awfully important of a detail to omit, since it entirely throws Deno’s numbers in the trash can when adjusted for CPU-time. Alternatively, allowing Bun the same amount of CPU-time, the numbers achieved with Bun absolutely towers those you can get with Deno, for the same juice.

It’s such an important detail to “mistakenly omit” that it makes the whole test seem rigged from the start. To verify a conclusion already decided on.

Another, less important detail but still an omitted detail is that Bun actually sits above a URL router capable of matching methods, URL wildcards and parameters, while Deno sits directly atop a raw HTTP server without any such capability built-in.

If we run the same test on a MacBook Air M1, with latest Bun v. latest Deno, we get the following:

• 179k req/sec for Deno.
• 334k req/sec for Bun.

These are staggering differences when taking into account you can practically scale linearly with number of CPU-cores utilized in this test.

Please - verify, verify, verify and think critically about what you read.

PS. Bun now writes the Date header properly on every response, just as Deno does, so the responses are identically long, and contains identical amounts of headers!