ConfigureAwait(false)性能测试

Question

我读到的任何地方都应该用它ConfigureAwait(false)来避免死锁和出于性能原因.我们正在使用ConfigureAwait我们的应用程序.但是可能会删除ConfigureAwaits,因为它会导致不同的线程的执行上下文.

不同线程的执行上下文导致(有时)翻译问题.由于当前文化和currentUICulture中的集合文化无法在不同的执行上下文中访问.

我用下面的代码测试了一下.它没有任何性能差异.我知道这不是一个好的测试,因为这个简单的测试没有使用很多线程.

static async Task MyMethodAsync()
{
  Stopwatch stopwatch = new Stopwatch();
  stopwatch.Start();
  for (int i = 0; i < 1000; i++)
  {
     await Task.Delay(10);
     await Task.Delay(10).ConfigureAwait(continueOnCapturedContext: false);
  }
  stopwatch.Stop();
  Console.WriteLine("Await: " + stopwatch.Elapsed.ToString());
}

static async Task MyMethodAsyncNoAwait()
{
  Stopwatch stopwatch = new Stopwatch();
  stopwatch.Start();
  for (int i = 0; i < 1000; i++)
  {
     await Task.Delay(10);
     await Task.Delay(10);
  }
  stopwatch.Stop();
  Console.WriteLine(stopwatch.Elapsed.ToString());
}

我该如何正确测试？删除所有ConfigureAwaits是一个非常糟糕的主意吗？

Answer 1

不要ConfigureAwait盲目使用性能.在编写代码(通常是库代码)时使用它,在同一线程/同步上下文中恢复无关紧要.如果在正确的线程/同步上下文中恢复很重要,ConfigureAwait(false)将会破坏您的代码,然后它的速度无关紧要.

Answer 2

您所做的与async-await性能无关，而是与响应性和可用性有关。

在 WinForms、WPF 或 UWP 等客户端 UI 上，它与响应能力有关。您使用async-awaitIO 和 CPU 绑定操作在 UI 线程之外执行工作并ConfigureAwait(false)明确避免返回到该 UI 线程。

在 ASP.NET（.NET Framework，而不是 .NET Core）上，它是关于可用性的。您使用async-awaiton IO 操作来释放线程来处理其他请求，并用于ConfigureAwait(false)避免将返回线程设置为 HTTP 上下文线程。

但是因为你总是在做更多的工作，所以每个逻辑操作都会花费更长的时间。

在客户端 UI 上，用户仍然可以使用应用程序，或者至少不会在标题栏和任务管理器上看到“无响应”短语。

在 ASP.NET 上，由于有更多线程可用于处理请求，因此在负载较重时，速度会更快，因为允许请求立即开始工作，而不是在请求队列中被阻塞。