Also in Deno 2.9, a hello-world program now cold-starts in about half the time it took in 2.8 (34ms down to 17ms), the company said. This improvement results from a combination of factors including lazy-loadingnode: globals out of the snapshot, gating the eager Node bootstrap to Node workers, a V8 code cache for residual lazy-loaded ESM modules, and a minified snapshot.
Deno 2.9 also brings improvements in memory usage, specifically memory under load. In Deno 2.8, resident set size grew with the workload, from roughly 94 MB serving plaintext to 197 MB streaming 1 MiB bodies, whereas in Deno 2.9 it stays essentially flat, holding around 62 MB no matter what the server is doing. This works out to 2.2x less peak resident set size on the real world workload scenario and 3.1x less on 1 MiB bodies, according to Deno Land. The upshot is that the same machine can run far more concurrent Deno.serveinstances before it runs out of headroom, the company said.
Further, HTTP throughput improvements in Deno 2.9 make Deno.serve faster across the board. Real-world workload scenario gains 1.27x, plaintext scenario gains 1.11x, and 1 MiB bodies scenario gains 1.18x, helped by a new Deno-owned HTTP/1.1 serving path, the company said.
