Overhead from threading-based solutions comes from two factors:

1. Context switching between threads is performed by the operating system. This implies context switching between user and kernel mode, and has higher overhead than equivalent switching between tasks by a scheduler within the application (e.g. “green threads” or an async executor/event loop). Furthermore, it is possible to use a cooperative multi-tasking approach within an application, whereas the OS has to use pre-emptive switches for security reasons. This could interrupt the application at a bad moment. A cooperative approach lets a task suspend itself at a moment where it has to wait anyway, reducing overhead to potentially zero. But this overhead is typically small anyway, so let’s disregard this.

2. Each operating-system level thread has some memory overhead. It needs to allocate its own stack space, usually a few KB. This overhead can turn into a hard limit when an application tries to start tens of thousands of threads of which most will just sleep until some I/O event occurs. In contrast, languages with async systems can represent the task state as an object or state machine, which can require far less space (often just a few 100 bytes or less). This makes it feasible to have millions of pending tasks. Memory is important because there’s only so much RAM you can economically pack into a single server.

What does this mean for power consumption? Async IO is not inherently more power-efficient, unless an event-based system replaces anti-patterns such as spin-wait loops. However, async approaches make it possible to handle way more pending tasks on a given system, thus allowing for higher density and more efficient use of a given hardware. This depends on the task at hand, of course. This won’t matter for CPU-bound tasks like numerical simulations. However, it matters a lot for typical web applications or microservices, where a request often spends most of its duration waiting for another service to respond. In that context, higher density can indirectly lead to more energy efficiency. If I need five servers to run a thread-based workload, but can get by with only four with an async-based implementation, one server can be turned off and doesn’t consume power.

For IO-bound work, asynchronous IO makes more efficient use of the hardware on a system than using separate system threads for the same purpose.

So if we can use async-IO to reduce the number of servers needed to run web server farm, I need less CPUs which means less power. So I would say ‘yes’ at a high level. The amount of saving is going to depend on how the load ratio you can get versus multi-threading. If you are running at the scale of Google or AWS, it could be significant.