Why is "Using asynchronous [...] methods on CPU-bound [providing] no benefits and results in more overhead."

Question

I came accross this article. And under "Choosing Synchronous or Asynchronous Action Methods" the author states that you should not use asyncronous action methods when:

The operations are primarily CPU operations instead of operations that involve extensive disk or network overhead. Using asynchronous action methods on CPU-bound operations provides no benefits and results in more overhead.

I do not understand why that would be so. Because if I have a method calculating the fibonacci numbers that takes up 30 seconds of computation that call is primarily CPU bound. Not making this async would block the calling thread for 30 seconds and make the application unresponsive.

Could you help me out with that reasoning?

Answer 1

Async programming is actually pretty vague to a lot of developers,me included.I always thought that async programming is concurrent,not parallel. Which means that we utilize it's waiting time in order to do something else and have the feel it is parallel. In reality however I stumbled upon this video couple of days ago.Link to video -> https://www.youtube.com/watch?v=il9gl8MH17s&lc=UgydFEXyhyXe7iAeR5J4AaABAg.9NxtCJSI5xK9O-YwEIp2KR It goes quite in depth with the state machine looked in CIL.But what we are interested is the part where he shows that the first thread is actually busy spinning one loop.Time stamp is 7:50. You can clearly see that while the one thread was blocked now and the waiting time was over in the KettleBoiling method,the method actually finished while the one thread was looping.He then checks to see the thread ID's and indeed. The .NET spawned a totally new thread for the function's completion.I've talked with the developer and he said that you don't know if it will be concurrent or parallel.The optimization will be done if needed.I will definitely do some more researching on this part but for now this is the best guide I can give.So having this knowledge (for now) I would say that it isn't actually hurting performance for CPU bound tasks.

EDIT** This is something that I found from Microsoft : If you have any I/O-bound needs (such as requesting data from a network, accessing a database, or reading and writing to a file system), you'll want to utilize asynchronous programming. You could also have CPU-bound code, such as performing an expensive calculation, which is also a good scenario for writing async code.

C# has a language-level asynchronous programming model, which allows for easily writing asynchronous code without having to juggle callbacks or conform to a library that supports asynchrony. It follows what is known as the Task-based Asynchronous Pattern (TAP). Link to text -> https://learn.microsoft.com/en-us/dotnet/csharp/async

Answer 2

Not making this async would block the calling thread for 30 seconds and make the application unresponsive.

You're confusing Concurrency and Parallelism. The author is talking about taking advantage of IO bound operations using async-await, where you can free calling threads while they're doing IO work such as a network or a database call, instead of blocking them synchronously until that operation completes.

What you're talking about is executing CPU bound work on background threads. In the context of ASP.NET, you're executing work on a dedicated thread that was allocated by the Thread-Pool. There is no use in spinning up a new thread just to do CPU bound work. For that, you can simply execute on the thread which is currently executing.

Also, using Task.Run in ASP.NET is considered dangerous. You should only off-load work with objects that register their work with the runtime environment, such as the BackgroundTaskManager.

If this were a UI app and you had a CPU bound operation, then deferring work to a background thread would be a valid thing to do, using Task.Run.