4 ms·

Deno introduced a new HTTP engine in 1.25 which apparently improved perf 3-4x. https://deno.com/blog/v1.25#new-experimental-http-server-api https://deno.com/bl

by pier25 4y ago

Deno introduced a new HTTP engine in 1.25 which apparently improved perf 3-4x. https://deno.com/blog/v1.25#new-experimental-http-server-api https://deno.com/blog/v1.25#new-experimental-http-server-api I guess this is not being used here? Edit: In fact in the HTTP benchmarks Deno seems to be much faster than Bun. https://deno.land/benchmarks#http-server-throughput https://deno.land/benchmarks#http-server-throughput

Jarred 4y ago
That new HTTP server (Deno.serve) is being used Bun’s http server is single-threaded, single-process right now. I think it’s really important to get single-threaded performance right before concurrency. Bun will eventually support builtin clustering/concurrency but it doesn’t yet
- akmittal 4y ago
  So Deno benchmark says deno is faster and bun says bun is faster? Thats why I hate benchmark by package author/publisher.
  - panzerboiler 4y ago
    If you want to see which one is faster (kind of pointless since both bun and deno/flash are not production ready) test your own application, and not an "hello world" or a specific workload that has been optimized to win a specific benchmark.
    - pier25 4y ago
      Deno is not production ready?
      - panzerboiler 4y ago
        The new fast webserver (flash) is still --unstable, hence not production ready. It has a performance comparable to nodejs+uWebSockets.js and bun (that should be using under the hood a slighly modified version of uWebSockets). edit: as a silly point of reference, an hello world that writes the same headers and the same body on a 2016 intel macbookpro is able to serve 125k rps in bun, 145k rps in deno/flash and 140k rps in nodejs+uws.
mhio 4y ago
The version of that graph in the readme links to `bun/bench/react-hello-world` [0] which makes use of `react-dom/server` so it is a slightly more involved test than sending plain `hello world` On a local 4 core VM, generating the load locally: Deno.serve() appears to be particularly bad for me at this test until you crank up the concurrent connections (>500) it gets up to 2k rps but it also falls over after that load. The `react-hello-world.node.js` server in node peaks at about 1.5k rps @ 32 connection Bun running react-hello-world.jsx gets 8k rps with 32 connections. This uses a customised local copy of `react-dom/server` where [1] at least the `escapeHTML` function is switched for bun's native implementation, and this appears to be packaged (or will be?) with bun [2]. I'm not sure if anything else is different here as the bun packaged code is still minified. The `bench/snippets/react-dom-render.bun.js` [3] test comparing these only show the bun version of `react-dom/server` to be 1.5 - 2x faster on this VM so it appears there is something more to it. Maybe everything `react-dom/server` normally stresses is optimised in bun? or `escapeHTML` is very large on the flamegraph. Running the react-hello-world.node.js server in bun results in about 1.9k rps @ 32 connection Running react-hello-world.deno.jsx in bun doesn't work. Futzing with react-hello-world.deno.jsx to load the cjs react builds will run in bun at about 1.9k rps 0: https://github.com/oven-sh/bun/tree/bun-v0.2.0/bench/react-hello-world https://github.com/oven-sh/bun/tree/bun-v0.2.0/bench/react-h... 1: https://github.com/oven-sh/bun/blob/bun-v0.2.0/test/bun.js/react-dom-server.bun.js#L202 https://github.com/oven-sh/bun/blob/bun-v0.2.0/test/bun.js/r... 2: https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/react-hello-world/react-hello-world.jsx#L1-L6 https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/react-h... 3: https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/snippets/react-dom-render.bun.js https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/snippet...

by pier25 4y ago

Jarred 4y ago

That new HTTP server (Deno.serve) is being used Bun’s http server is single-threaded, single-process right now. I think it’s really important to get single-threaded performance right before concurrency. Bun will eventually support builtin clustering/concurrency but it doesn’t yet

akmittal 4y ago
So Deno benchmark says deno is faster and bun says bun is faster? Thats why I hate benchmark by package author/publisher.
- panzerboiler 4y ago
  If you want to see which one is faster (kind of pointless since both bun and deno/flash are not production ready) test your own application, and not an "hello world" or a specific workload that has been optimized to win a specific benchmark.
  - pier25 4y ago
    Deno is not production ready?
    - panzerboiler 4y ago
      The new fast webserver (flash) is still --unstable, hence not production ready. It has a performance comparable to nodejs+uWebSockets.js and bun (that should be using under the hood a slighly modified version of uWebSockets). edit: as a silly point of reference, an hello world that writes the same headers and the same body on a 2016 intel macbookpro is able to serve 125k rps in bun, 145k rps in deno/flash and 140k rps in nodejs+uws.

mhio 4y ago

The version of that graph in the readme links to `bun/bench/react-hello-world` [0] which makes use of `react-dom/server` so it is a slightly more involved test than sending plain `hello world` On a local 4 core VM, generating the load locally: Deno.serve() appears to be particularly bad for me at this test until you crank up the concurrent connections (>500) it gets up to 2k rps but it also falls over after that load. The `react-hello-world.node.js` server in node peaks at about 1.5k rps @ 32 connection Bun running react-hello-world.jsx gets 8k rps with 32 connections. This uses a customised local copy of `react-dom/server` where [1] at least the `escapeHTML` function is switched for bun's native implementation, and this appears to be packaged (or will be?) with bun [2]. I'm not sure if anything else is different here as the bun packaged code is still minified. The `bench/snippets/react-dom-render.bun.js` [3] test comparing these only show the bun version of `react-dom/server` to be 1.5 - 2x faster on this VM so it appears there is something more to it. Maybe everything `react-dom/server` normally stresses is optimised in bun? or `escapeHTML` is very large on the flamegraph. Running the react-hello-world.node.js server in bun results in about 1.9k rps @ 32 connection Running react-hello-world.deno.jsx in bun doesn't work. Futzing with react-hello-world.deno.jsx to load the cjs react builds will run in bun at about 1.9k rps 0: https://github.com/oven-sh/bun/tree/bun-v0.2.0/bench/react-hello-world https://github.com/oven-sh/bun/tree/bun-v0.2.0/bench/react-h... 1: https://github.com/oven-sh/bun/blob/bun-v0.2.0/test/bun.js/react-dom-server.bun.js#L202 https://github.com/oven-sh/bun/blob/bun-v0.2.0/test/bun.js/r... 2: https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/react-hello-world/react-hello-world.jsx#L1-L6 https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/react-h... 3: https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/snippets/react-dom-render.bun.js https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/snippet...