And if you step out all the parallelism from your concurrency runtime, you get rid of a big chunk of the overhead. But even with purely cooperative single-threaded multitasking, there's still some overhead vs "ordinary" strictly serial code.

For CPU bound code, concurrency is pure overhead.

For I/O bound code, concurrency can give you some benefit.

...but in general, people do not analyse this before throwing tasks at a problem.

> ...but in general, people do not analyse this before throwing tasks at a problem.

Would that be just anecdotal ?

yes... in ~25 years in the business, over ~10 companies.

..and I can tell you that precisely none of them performed a correct analysis of a systems concurrency needs before 'designing' it.

A common artifact of this is far too many tasks.

I have seen egregious abuse of pre-emptive threads ... a lot. Abuse of green threads / fibres / coroutines ... not so much. I think one has to be a half decent programmer to be even aware those options.