One thing that helps is the binary size is tiny and the memory usage patterns are tight. It's bloat that usually makes fork() go slow, since if you have a lot of little pieces updating disparate memory locations, then you're going to have a lot of page faults. Redbean was built with a singular first-principles vision. When I started working on this, all I had was an empty file and an assembler. As such, I spent a lot of time using things like linker scripts to organize exactly where in the binary code gets relocated.

>have a lot of little pieces updating disparate memory locations, then you're going to have a lot of page faults.

This is wonderful, just thinking out loud. Out of interests would something like ECS (Entity Component System) be useful or yield better memory usage since it should in theory trash the cache less ?

Just guessing here, but redbeam likely does not have to access the filesystem as the files are in the binary and thus saves on syscalls and context switches.