Why sometimes async and await are bad for your app

Поділитися
Вставка
  • Опубліковано 15 жов 2024
  • Hi there! Today we are going to see why sometimes is better to use synchronous code instead of asynchronous.
    Add vs AddAsync - Which one should you use? : • Add vs AddAsync - Whic...
    #csharp #dotnet #asynchronous

КОМЕНТАРІ • 2

  • @yezinia
    @yezinia Рік тому +2

    Bro, your Benchmark is really bad. At first it is a very limited example. Second you are comparing an synchronous implementation to an asynchronous implementation with a synchronous problem. Maybe you should add a more complex calculation example to benchmark both approaches. Something like sum up 1000 lists where each list contains 100k entries. Then lets see how your synchronous code performs campared to your async implementation.
    The next thing is that asynchronous code is not meant to make your code "faster", but more responsive. This is the key takeaway of async await. You trade a little bit of synchronous performance for an unblocking application in a mulit threaded environment. So saying that async await should only be used with long running tasks or IO Operations is not correct. Action Methods in MVC should be using async await as well to ensure that the server can handle large loads of requests.
    But you do not have to await every task. In some cases it is totally fine to just return a Task without awaiting it and let the consumer of the task decide when to wait for this. Async code is nothing that is is easy and nothing for what simple rules apply.

    • @spyroskatsios
      @spyroskatsios  Рік тому +3

      That's the point. That using asynchronous implementation with synchronous code is not ideal. That's why i used the EF example and i mentioned libraries, like the EF, that provide sync and async methods for the same operation.
      That's exactly what I said. That there is always going to be an overhead, but the benefits outweigh that in some cases because we delegate the task to a different thread, so the current one is free to do other work.
      About the third argument I don't know what does it have to do with this video. Yes, if you are inside a method that returns a task and the only async call is to calculate the returned result you can return that without waiting it. But that's not always the case and again someone needs at some point to await that and you still have some overhead.
      Overall i don't think that i communicated something different from what you wrote in your first two paragraphs.