> Why choose async/await over threads? I assume the intended question is: why use async/await over thread-per-client designs? Easy: because async/await allows

> Why choose async/await over threads? I assume the intended question is: why use async/await over thread-per-client designs? Easy: because async/await allows you to more easily compress the memory footprint of client/request/work state because there is no large stack to allocate to each client/whatever. One can still use threads (or processes) with async/await so as to use as many CPUs as possible while still benefiting from the state compression mentioned above. State compression -or, rather, not exploding the state- is critical for performance considering how slow memory is nowadays. Async/await, manual continuation passing style (CPS) -- these are great techniques for keeping per-client memory footprint way down. Green threads with small stacks that don't require guard pages to grow are less efficient, but still more efficient than threads. Threads are inefficient because of the need to allocate them a large stack, and to play MMU games to set up those stacks and their guard pages. Thread-per-client simply does not scale like async/await and CPS.