|
|
|
|
|
by Mawr
1066 days ago
|
|
Horrible overhead. If the loop does something simple, like summing integers, 99% of time will be spent switching between goroutines. From TFA: "Because scheduling is explicit (without any preemption) and done entirely without the operating system, a coroutine switch takes at most around ten nanoseconds, usually even less. Startup and teardown is also much cheaper than threads." "For this taxonomy, Go's goroutines are cheap threads: a goroutine switch is closer to a few hundred nanoseconds" Also check out https://news.ycombinator.com/item?id=29510751 and https://ewencp.org/blog/golang-iterators/index.html: "Finally, the most natural channel based implementation is… slow. By a factor of nearly 50x. Buffering does help though, reducing that to a factor of 25x." |
|
If you try to implement this pattern by hand, you are all too likely to make fatal mistake, and this is doubly true in the hands of an inexperienced programmer.
I appreciate the fact that Russ wrote this long post, gradually implementing `coro.New()` and improving its functionality and safety — and only in the very end, we get a short paragraph about performance. Good performance is important to make this feature attractive to use, but if the feature is clunky and error-prone, it wouldn't be worth much, even with great performance.