CODEWITHSUNDEEP
c#.netasp.net-mvcasynchronousasync-await
GIVE-ME-CHICKEN
GIVE-ME-CHICKEN

Reputation: 1269

Is it necessary for a controller action that only returns a view to be asynchronous?

Take this basic action:

[HttpGet]
public IActionResult Index()
{
    return View();
}

Modify it to make use of async/await:

[HttpGet]
public async Task<IActionResult> Index()
{
    return await Task.Run(() => View());
}

I am confused whether this will improve my code or not. From my understanding, the await keyword will release the calling thread so that it may be available for use elsewhere, which is better utilisation of available threads.

But I am not actually doing anything else except this one thing which is returning a view. Having the async keyword actually introduces a state machine within the compiled code, which adds complexity.

Is making this action asynchronous worth it? Is there a better way of modifying it to make it asynchronous?

Upvotes: 2

Views: 159

Answers (2)

Kevin B Burns
Kevin B Burns

Reputation: 1067

It sounds to me that you should revisit Microsoft's TAP document, and get a better grasp of how you can make Task work for you.

In your example:

public Task<IActionResult> Index()
{
    return Task.FromResult(View());
}

It is just essentially returning some HTML, Javascript, and CSS, so it would be less than pointless, meaning, when you add Task to a normal function, there is overhead that can become costly.

Now if you had something like this:

public Task<IActionResult> Index()
{
    var users  = DbContext.GetUsersAsync();
    var groups = DbContext.GetGroupsAsync();

     await Task.WhenAll(users,groups);

    var m = new Model(){
     Users = users.Result,
     Groups = groups.Result
    }

    return View(m);
}

In this scenario, Task makes sense, you are essentially performing two different I/O functions at the same time, then waiting for all of them to finish before moving on. You are taking the amount of time that it would have taken to process each call individually, and cutting it down by hopefully half ( at the cost of blocking a potential CPU thread for another "web" user to access the same document.)

 public Task<IActionResult> Index()
    {
        var users  = await DbContext.GetUsersAsync();
        var groups = await DbContext.GetGroupsAsync();

        var m = new Model(){
         Users = users,
         Groups = groups
        }

        return View(m);
    }

In my third example, even though it using Async / Await, it is still running everything one-by-one, so wasting precious Threads.

The only thing that I can recommend is that Task does not scale well with a large user-base, so while developing your web solution, keep in mind the potential future growth of users and lean-back on the usage of Task-based functions.

https://learn.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap

Upvotes: 2

driis
driis

Reputation: 164341

The short answer is No. Since there is nothing async going on in View() there are no places in the execution where the compiler can release the thread to allow for other work to happen on the same thread.

I would say making this particular method async might be (even so slightly) worse for performance, since the compiler will need to modify your code, making what's executed more complex, once you use the async keyword.

The only benefit in making it async that I can see would be for consistency if you have a lot of other actions that are in fact taking advantage of async. If you really want to have a Task<T>signature for consistency purposes, you could consider:

public Task<IActionResult> Index()
{
    return Task.FromResult(View());
}

(Notice no async keywords involved and no Task.Run spinning up a new task to run)

Upvotes: 5

Related Questions