由于异步I/O的优点，它现在很容易编写和编写（使用Await和TAP方法），我想知道，如果我们应该默认使用异步并且只在需要时使用同步来调整性能。我们是否应该默认切换到使用异步I/O？
异步I/O释放调用线程，并允许在等待结果时执行其他操作。另一方面，异步I/O比同步慢一点。
为了实施响应式用户界面，WinRT设计人员发现它可以接受提供异步方法。
AFAIK Windows文件I/O内部是异步的。仔细看这个，我不清楚为什么.NET中的异步文件I/O应该比同步更慢。
我通常喜欢简单性和健壮性，并且只在必要时调整性能。在过去，我们默认情况下使用同步，除了调用某些服务以及像手机这样的平台强制执行异步。我们很少通过使用异步来调整。
在C＃5中使用异步IO变得非常容易，但仍然存在与其相关的生产力成本。例如，您需要在以前没有的地方洒新的关键字。你必须改变你的方法的返回类型。
如果您以后决定某个方法应该执行IO，则必须更改整个调用链才能切换到异步。这是一个非本地变化传播到其他模块。
您无法配置异步IO。分析工具没有提到任何东西。如果暂停调试器，则任何线程堆栈上都不存在。似乎没有人做任何事情。这是因为异步IO不包含线程。它只是一个数据结构（内核中的一个对象）。
该决定还取决于应用程序类型。在WinForms或WPF应用程序中，我宁愿使用异步，因为它非常好地集成到UI线程中。
在ASP.NET/WCF设置中，主要优点是在调用长时间运行的后端服务时不会耗尽线程池。如果你没有这样的问题，我认为这很少见，你从异步IO中获得的很少。事实上，你默认情况下表现不佳。
在地铁设置中，您已做出决定。微软（合法）选择为用户体验交易开发人员生产力。
所以这不是一个明确的决定。在这一点上，利弊都很薄弱。出于这个原因，我不要提出明确的建议。这很大程度上取决于具体情况。
我建议在自然异步操作时使用async，否则使用同步代码。确实，async稍微慢一些，但在大多数情况下，它就像“嗡嗡声”中的收音机放慢一样。
在UI程序中，async增加了响应性。在服务器应用程序中，async增加了可伸缩性。
AFAIK Windows文件I/O内部是异步的。仔细看这个，我不清楚为什么.NET中的异步文件I/O应该比同步更慢。
异步代码比较慢，因为它必须分配结构来跟踪异步操作;同步代码只使用当前线程（及其堆栈）。所以操作本身并不慢，但总的来说，由于垃圾收集器的压力更大，所以速度略有下降。
我一般都喜欢简单性和健壮性，并且只在需要时调整性能。
我同意。如果您有一个自然异步的操作（如I/O），请提供一个async API。如果你有一个自然同步的操作，则公开一个同步API。 Stephen Toub在这方面有一些很棒的博客文章（here和here）。
的[pfxteam博客]（http://msdn.microsoft.com/en-us/magazine/jj133817.aspx）包含在这方面的一些有趣的信息： *“请注意，我们没有添加的异步版本API的粒度非常小，如TextReader.Peek，原因是异步API还会增加一些开销，并且我们希望防止开发人员误入歧途，这也意味着我们专门决定不提供方法的异步版本在BinaryReader或BinaryWriter .... * –