我们应该默认切换到使用异步I/O吗？

Question

利用异步I/O的优点,它现在很容易编码和编写(使用Await和TAP方法),我想知道,如果我们应该默认使用async,只需要在需要时使用sync来调整性能.

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

为了实施响应式UI,WinRT设计人员认为提供仅异步方法是可以接受的.

内部的AFAIK Windows文件I/O是异步的.天真地看着这个,我不清楚为什么.NET中的异步文件I/O应该比同步慢.

我通常喜欢简单性和健壮性,只在必要时调整性能.在过去,我们默认使用同步,除了调用某些服务以及手机等平台强制执行异步.我们很少使用异步调整.

Answer 1

使用异步IO在C#5中变得非常容易,但仍然存在与之相关的生产力成本.例如,您需要在必要时先填写新关键字.您必须更改方法的返回类型.

如果您稍后决定某个方法应该执行IO,则必须更改整个调用链以切换到异步.这是一种非局部的变化,传播到其他模块.

您无法分析异步IO.分析工具一无所获.如果您暂停调试器,则任何线程堆栈都不会出现任何问题.似乎没有人做任何事情.那是因为异步IO不包含线程.它只是一个数据结构(内核中的一个对象).

决定还取决于应用程序类型.在WinForms或WPF应用程序中,我宁愿选择异步,因为它很好地集成到UI线程中.

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

在地铁环境中,您已做出决定.微软(合法地)选择交换开发人员的工作效率以获得用户体验.

所以这不是一个明确的决定.在这一点上,利弊都非常薄弱.出于这个原因,我不提出明确的建议.这在很大程度上取决于具体情况.

Answer 2

我推荐async在你有自然异步操作时使用,否则建议使用同步代码.确实async稍微慢一点,但在大多数情况下,它就像"悍马中的收音机"更慢.

在UI程序中,async提高响应能力.在服务器应用程序中,async增加可伸缩性

内部的AFAIK Windows文件I/O是异步的.天真地看着这个,我不清楚为什么.NET中的异步文件I/O应该比同步慢.

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

我通常喜欢简单性和健壮性,只在必要时调整性能.

我同意.如果您有一个自然异步的操作(例如I/O),则公开asyncAPI.如果您有一个自然同步的操作,则公开同步API.Stephen Toub有一些很棒的博客文章(这里和这里).