配置等待和性能

Question

1. await MyMethnodAsync()await MyMethnodAsync().ConfigureAwait(true)从程序运行的角度来看它们是否相同？
2. ConfigureAwait(false)总能提高性能？
3. 什么时候能ConfigureAwait(false)提高性能？
4. 什么时候能ConfigureAwait(true)提高性能？

Answer 1

1. 在撰写本文时，“是的，是的”；那里的“ish”是因为 a: 需要执行少量的额外代码（将您的首选项显式存储在结构体等中），并且 b:await MyMethnodAsync()适用于 的任何可等待返回值，MyMetnodAsync但.ConfigureAwait仅实现了（至少默认情况下）在某些特定的（尽管很常见）可等待类型上；等待的事情比你想象的要多；例如，await Task.Yield().ConfigureAwait(true);由于这个原因无法编译；“在撰写本文时”是因为我希望有一天可能会有某种程序集/模块级默认值与编译器一起工作以自动执行默认值，因此对于一个库，您可以说，例如[module:ConfigureAwaitDefault(false)]-但是：今天不存在（也不存在于我所知道的任何计划中）
2. 不; 如果没有同步上下文，它不会产生任何功能差异 - 并且在许多情况下（例如现代 ASP.NET、控制台 EXES、服务 EXES）没有同步上下文（默认情况下）；当存在同步上下文时，仍然不能保证会产生任何性能差异；这不是重点，真的；真正的要点很简单：“如果有同步上下文，我需要使用它吗？我是否主动不需要使用它？我是否关心我是否使用它，如果是的话，我是否应该宁愿不使用它？”；对于与 UI 等无关的库代码，答案通常（并非总是）应该是“我应该避免它，即使有一个”；对于应用程序代码，最安全的答案通常是“如果有的话，我应该使用它”
3. 当同步上下文存在时，并且会施加某种限制/瓶颈，可能是由于在单个工作循环上序列化回调（如 winforms 的情况）；或者更糟糕：同步上下文可能会导致死锁情况（我猜死锁是性能不佳的最终结果？）
4. 理论上，除了执行值任务操作的琐碎步骤之外，它不应该在任何方向上对性能产生影响