async attendent les performances?

Un objet Task représente le résultat différé d'une opération en attente. Vous n'avez pas besoin d'utiliser tasks et async/await Si vous n'avez pas d'opérations en attente. Sinon, je crois async/await le code est généralement plus efficace que son analogue NU TPL ContinueWith.

Faisons un peu de timing:

using System;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApplication
{
    class Program
    {
        // async/await version
        static async Task<int> Test1Async(Task<int> task)
        {
            return await task;
        }

        // TPL version
        static Task<int> Test2Async(Task<int> task)
        {
            return task.ContinueWith(
                t => t.Result,
                CancellationToken.None,
                TaskContinuationOptions.ExecuteSynchronously,
                TaskScheduler.Default);
        }

        static void Tester(string name, Func<Task<int>, Task<int>> func)
        {
            var sw = new System.Diagnostics.Stopwatch();
            sw.Start();
            for (int i = 0; i < 10000000; i++)
            {
                func(Task.FromResult(0)).Wait();
            }
            sw.Stop();
            Console.WriteLine("{0}: {1}ms", name, sw.ElapsedMilliseconds);
        }

        static void Main(string[] args)
        {
            Tester("Test1Async", Test1Async);
            Tester("Test2Async", Test2Async);
        }
    }
}

La sortie:

Test1Async: 1582ms
Test2Async: 4975ms

Ainsi, par défaut, await continuations sont traitées plus efficacement que ContinueWith continuations. Optimisons légèrement ce code:

// async/await version
static async Task<int> Test1Async(Task<int> task)
{
    if (task.IsCompleted)
        return task.Result;
    return await task;
}

// TPL version
static Task<int> Test2Async(Task<int> task)
{
    if (task.IsCompleted)
        return Task.FromResult(task.Result);

    return task.ContinueWith(
        t => t.Result,
        CancellationToken.None,
        TaskContinuationOptions.ExecuteSynchronously,
        TaskScheduler.Default);
}

Le sortie:

Test1Async: 1557ms
Test2Async: 429ms

Maintenant, la version non asynchrone gagne. Dans le cas de la version async, je crois que cette optimisation a déjà été effectuée en interne par l'infrastructure async/await.

Quoi qu'il en soit, jusqu'à présent, nous n'avons traité que des tâches terminées (Task.FromResult). Introduisons l'asynchronie réelle (naturellement, nous ferons moins d'itérations cette fois):

static Task<int> DoAsync()
{
    var tcs = new TaskCompletionSource<int>();
    ThreadPool.QueueUserWorkItem(_ => tcs.SetResult(0));
    return tcs.Task;
}

static void Tester(string name, Func<Task<int>, Task<int>> func)
{
    ThreadPool.SetMinThreads(200, 200);
    var sw = new System.Diagnostics.Stopwatch();
    sw.Start();
    for (int i = 0; i < 1000000; i++)
    {
        func(DoAsync()).Wait();
    }
    sw.Stop();
    Console.WriteLine("{0}: {1}ms", name, sw.ElapsedMilliseconds);
}

La sortie:

Test1Async: 4207ms
Test2Async: 4734ms

Maintenant, la différence est très marginale, bien que la version async fonctionne encore légèrement mieux. Pourtant, Je pensez qu'un tel gain est vraiment négligeable, comparable au coût réel de l'opération asynchrone ou au coût de la restauration du contexte capturé pour when SynchronizationContext.Current != null.

L'essentiel est, si vous traitez des tâches asynchrones, optez pour async/await Si vous avez le choix, pas pour des raisons de performance mais pour la facilité d'utilisation, la lisibilité et la maintenabilité.