1. Yes, C# version works faster even if 1 “yield” is eliminated — you can do this by using a custom scheduler. A version with no “yield”s is expected to be faster.
  2. I’ve also checked out Asynqueue tests — yes, it’s faster as well, though the test is a bit different there: it passes 1M messages through the same channel, not different ones. + Asynqueue itself isn’t a library for async computatations — it solves a specific problem (message passing), though doesn’t seem to implement something allowing you to run millions of actors / task-like objects — again, this is based solely on a brief studying of their source code. Nevertheless, what they’ve done is still very impressive.
  3. I am hesitant to publish exactly these findings right now — mostly because this is not an apples-to-apples comparison w/ Go. I understand it’s hard or impossible to implement a true apples-to-apples comparison here, but I still feel there is a good room for improvements. So I am thinking of what should be a good “another try” here, but likely, the best way to do that is to start working together on a shared GitHub repo with a better benchmark for this.
  4. Even now it’s clear that C# is ~ on par with Go in terms of speed of async computations — i.e. “clear advantage of goroutines over async/await” is a myth.

Creator of https://github.com/servicetitan/Stl.Fusion , ex-CTO @ ServiceTitan.com