[detaro]

And a real-world deployment of a single-threaded interpreter just runs multiple instances of it, so do and compare that. No need to "handicap" anything.

[zamalek]

My gut would say that you're paying 2x the overhead for a JS runtime. Of course, such a benchmark (edit: N instances of Bun and N instances of Deno) would be much more realistic/relevant.

[m00x]

But then you need twice the initial app memory. This can be substantial for larger apps.

There are definitely benefits of using multiple cores at once on a single app.

[detaro]

Sure. not an excuse to not benchmark it that way - if it struggles due to memory it'll show up after all.

[simpsond]

Copy on write fork mitigates some of that.

[squeaky-clean]

There was a recent post about a new Ruby server implementation. The author pointed out that for interpreted languages, forking quickly deviates and gains very little benefit from copy-on-write. However! Pre-warming the first instance and then forking afterwards brought the memory savings back down to compiled levels. No real point to my comment except that it was new knowledge to me, and that efficiency of forking really depends on the implementation of what/when you're forking.

[m00x]

It's not clear what OP is saying. I assumed multiple container instances, but even then, CoW isn't as efficient.