异步等待性能？

Question

（只是一个理论问题 - 对于非gui应用程序）

假设我有很多awaits代码：

public async Task<T> ConsumeAsync()
    {
          await A();
          await b();
          await c();
          await d();
          //..
    }

每项任务可能需要很短的时间，

问题 （再次，理论）

可能存在这样一种情况： 整个时间处理所有那些“释放回线程”和“取回线程”（红色和绿色在这里:)

花费的时间比单个线程花费更多的时间，可以通过少量延迟完成所有工作，

我的意思是，我想成为最富有成效的人，但相反，因为所有这些来回切换 - 我实际上失去了生产力。

这种情况会发生吗？

Answer 1

是的，从理论上讲。 通常情况下，在现实世界中。

在常见的情况下， async用于I / O绑定操作，并且与它们相比，线程管理的开销是不可检测的。 大多数情况下，异步操作要么花费很长时间（与线程管理相比），要么已经完成（例如，缓存）。 请注意， async有一个“快速路径”，如果操作已经完成，它就会启动，它不会产生线程。

有关更多信息，请参阅Async和Async Performance的Zen 。

Answer 2

Task对象表示挂起操作的延迟结果。 如果您没有任何挂起操作，则不必使用任务和async/await 。 否则，我相信async / await代码通常比它的裸TPL ContinueWith模拟更有效。

我们来做一些时间：

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);
        }
    }
}

输出：

Test1Async: 1582ms
Test2Async: 4975ms

因此，默认情况下， await continuation的处理比ContinueWith continuation更有效。 让我们稍微优化一下这段代码：

// 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);
}

输出：

Test1Async: 1557ms
Test2Async: 429ms

现在，非异步版本获胜。 对于async版本，我相信这种优化已经由async/await基础架构在内部完成。

无论如何，到目前为止，我们只处理完成的任务（ Task.FromResult ）。 让我们介绍一下实际的异步（当然，这次我们会做更少的迭代）：

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);
}

输出：

Test1Async: 4207ms
Test2Async: 4734ms

现在差异非常小，尽管async版本仍然表现稍好一些。 然而，我认为这种收益实际上是可以忽略的，可与异步操作的实际成本相比，或者与SynchronizationContext.Current != null时恢复捕获的上下文的成本相当。

最重要的是，如果您处理异步任务，请选择async / await如果您有选择，不是出于性能原因，而是为了易用性，可读性和可维护性。

Answer 3

这种情况会发生吗？

绝对。 因此，您应该认真对待使用异步代码的位置。 通常，您最好将其用于实际执行异步操作的方法（例如，磁盘或网络I / O）。 这些操作所花费的时间通常远远超过在线程上调度任务的成本。 此外，在操作系统级别，这些类型的操作本质上是异步的，因此您实际上是通过使用异步方法删除了一个抽象层。

但即使在这些情况下，除非能够利用并发性，否则通过切换到异步代码可能看不到明显的性能差异。 例如，您发布的代码可能看不到实际的性能增益，除非它被更改为这样的东西：

await Task.WhenAll(new[]{A(), B(), C(), D(), ...});

Answer 4

是的，它可能发生。 另外不要忘记 - 你可以编程的所有效率 - 任务系统都有开销。

如果你对这样的事情太过粗暴，那么同步开销可以杀死你。 这意味着：任务编程非常有效。

但旧规则坚持：不要超细颗粒。 SOmetimes优化有帮助。

Answer 5

是的，当然可以发生。 利用创建状态机的所有开销，来回控制和使用IOCP线程。 但TPL ， TPL已经过优化。 例如，不要忘记，如果您的TaskAwaitable快速完成，则可能没有开销，并且它将同步执行，这可能通常在快速操作时发生。