我们是否应该在默认情况下切换为使用异步I/O？

Question

有了异步I/O的优点，而且现在很容易编码和编写(使用Await和TAP方法)，我想知道我们是否应该在默认情况下使用异步，只有在需要时才使用同步来调整性能。

异步I/O释放了调用线程，并允许在等待结果时执行其他操作。另一方面，异步I/O比同步稍慢一些。

为了执行响应式UI，WinRT设计人员发现可以接受仅提供异步方法。

AFAIK Windows文件I/O内部是异步的。从天真的角度来看，我不清楚为什么.NET中的异步文件i/O应该比同步慢。

我通常倾向于简单性和健壮性，并且只在必要时针对性能进行调优。在过去，我们默认使用同步，除了调用一些服务和像手机这样的平台强制异步。我们很少使用异步进行调优。

Answer 1

在C# 5中，使用异步IO变得非常简单，但仍然存在与之相关的生产力成本。例如，您需要在以前没有关键字的地方，在必要的地方散布新的关键字。你必须改变你的方法的返回类型。

如果您后来决定某个方法应该执行IO，则必须更改整个调用链以切换到异步。这是一个传播到其他模块的非本地更改。

您无法分析异步IO。分析工具什么也得不到。如果暂停调试器，则任何线程堆栈上都没有任何内容。似乎没有人在做任何事情。这是因为异步IO不包含线程。它只是一个数据结构(内核中的一个对象)。

该决定还取决于应用程序类型。在WinForms或WPF应用程序中，我更喜欢使用异步，因为它可以很好地集成到UI线程中。

在ASP.NET/WCF设置中，主要优点是在调用长时间运行的后端服务时不会耗尽线程池。如果你没有这样的问题，我认为这是相当罕见的，你从异步IO中获得的好处很少。事实上，在默认情况下，您会降低性能。

在Metro设置中，已经为您做出了决定。微软(合法地)选择牺牲开发人员的生产力来换取用户体验。

因此，这不是一个明确的决定。在这一点上，正反两方面都很弱。出于这个原因，我不会给出一个明确的建议。这在很大程度上取决于具体情况。

Answer 2

我建议在有自然异步操作时使用async，在其他情况下使用同步代码。async确实稍微慢了一点，但在大多数情况下，它就像是“打开你的悍马车里的收音机”一样慢。

在UI程序中，async提高了响应性。在服务器应用程序中，async提高了可伸缩性。

AFAIK Windows文件I/O内部是异步的。从天真的角度来看，我不清楚为什么.NET中的异步文件i/O应该比同步慢。

异步代码比较慢，因为它必须分配结构来跟踪异步操作；同步代码只使用当前线程(及其堆栈)。因此，操作本身并不慢，但由于垃圾收集器的压力较大，总体上速度略有下降。

我通常更喜欢简单性和健壮性，并且只在必要时针对性能进行调优。

我同意。如果您有一个本质上是异步的操作(例如I/O)，则公开一个async应用程序接口。如果你有一个自然同步的操作，那就公开一个同步API。Stephen Toub在这方面有几篇很棒的博客文章(here和here)。