On Sat, 07 Dec 2013 08:51:22 GMT, Sergei Nosov wrote:

On Sat, 07 Dec 2013 08:33:22 GMT, Sönke Ludwig wrote:

As long as everything is I/O bound, which can be considered a common case when DB queries and sizable pages are generated, a single thread is the most efficient choice.

Thanks, that actually makes a lot of sense.

  1. A good alternative can be to do complex computations using runWorkerTask (which lets the task run in one of the worker threads) and let all I/O and request processing still happen in the main thread. This can often avoid explicit synchronization, while still fully exploiting the CPU's cores and thus simplifies the overall program architecture and may give a performance advantage.

I believe, this can be thought of as you treat heavy-CPU parts of the program as just another asynchronous I/O operations. Thank you for the insights!

Also if there is a continuous CPU-heavy task, it may be effective to delegate it to own thread with hard processor affinity set (don't know if vibe.d / Phobos provides wrappers for that) - impact of effective instruction cache can sometimes be huge. As a general rule of a thumb - every time you lock for shared resources in multiple threads you have opportunity to improve your program concurrent architecture ;)