3 ms·
Not true: https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/#channels-are-slower-than-implementing-it-yourself:7de476e370ca6a780a51fd68
by unscaled 6y ago
Not true:
https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/#channels-are-slower-than-implementing-it-yourself:7de476e370ca6a780a51fd680c5a51dd https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s...
I'm pretty sure the implementation has seen some improvements since then. But using a channel for async await is the same as using a global mutex every time you await. That is bound to be contentious on high load.
- Taek 6y agoI think today channels cost a few hundred nanoseconds. For most applications, this is 'close to no overhead'. If you are doing a really tight loop of course or have threads that bump into eachother a million times per second, you're going to want a different primitive. But most programmers aren't going to see any overhead using channels instead of something else.
- unscaled 6y agoPlease remember the approach is "every context switch should go through a centralized channel". This including waiting on all other channels. I need to see some benchmark to this level to be proven the overhead is negligible. And of course, there is still the question of WHY would you ever want to do that. What can be gained from simulating an async-await model on top of a channel.