ConfigureAwait(假)性能测试
在我读到的任何地方，我都应该使用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真的是个坏主意吗？
回答 2
Stack Overflow用户
发布于 2017-06-07 09:26:33
不要盲目地使用ConfigureAwait来提高性能。当编写代码(通常是库代码)时使用它，在相同的线程/同步上下文上恢复并不重要。如果在正确的线程/同步上下文上恢复确实很重要，ConfigureAwait(false)会破坏您的代码，然后不管它的速度有多快。
Stack Overflow用户
发布于 2017-06-08 00:01:22
您对async-await所做的不是性能问题，而是响应性和可用性。
在客户端UI(如WinForms、WPF或UWP )上，它是关于响应性的。您可以在IO和CPU绑定操作上使用async-await来执行UI线程和ConfigureAwait(false)之外的工作，从而显式地避免返回到该UI线程。
在ASP.NET (.NET框架，而不是.NET核心)上，它是关于可用性的。您可以在IO操作上使用async-await来释放线程以处理其他请求，并使用ConfigureAwait(false)来避免将返回线程设置为HTTP线程。
但是因为你总是做更多的工作，每一个逻辑运算都要花费更长的时间。
在客户端UI上，用户仍然可以使用应用程序，或者至少不能在标题栏和任务管理器上得到“不响应”的短语。
在ASP.NET上，因为有更多可用的线程来处理请求，在负载很重的情况下，它会更快，因为请求可以立即开始工作，而不是在请求队列中被阻塞。
https://stackoverflow.com/questions/44408504
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号