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上，它與響應能力有關。 您可以在IO和與CPU綁定的操作上使用async-await來在UI線程之外進行工作，並使用ConfigureAwait(false)來明確避免返回該UI線程。

在ASP.NET（.NET Framework，而不是.NET Core）上，它與可用性有關。 您可以在IO操作上使用async-await來釋放線程以處理其他請求，並使用ConfigureAwait(false)以避免將返回線程設置為HTTP Context線程。

但是，由於您總是要做更多的工作，因此每個邏輯操作將花費更長的時間。

在客戶端UI上，用戶仍將能夠使用該應用程序，或者至少在標題欄和任務管理器上無法獲得該“不響應”的短語。

在ASP.NET上，由於有更多線程可用於處理請求，因此在負載較重時，它將更快，因為允許請求立即開始工作，而不是被阻塞在請求隊列中。