Gemma Black of course, glad I could help :)

Gemma Black even that may not be enough. If I'm reading it right, the callbacks test is only blocking once, and it's still running 10000 reads in parallel, while the async test is blocking 10000 times to run reads sequentially. You may need to launch the next readFile only after the previous one completed (ie inside it's callback).

Interesting benchmarking work, and surprising results! I think I found why it looks so skewed against async/await. Looking at the docs , it looks like the callbacks test is missing a call to the second argument of the test callback function. This is what test runners use to know that async work has finished. Otherwise, the test is firing 10000 iterations without waiting for the previous ones to finish, unlike what's happening in the async/await test. I imagine the same must be happening with promises. So, for a fairer comparison, I believe either the callback and promises tests should call the second argument of the test callback to block like the async/await, or the async/await test should drop the await so that it fires all iterations at once like the others. In any way, I agree that always blocking on any async work is slow mode and no better than other languages. It's when we can parallelise multiple async work that node truly shines!