.net - Should we switch to use async I/O by default?

Question

With the advantages of async I/O and it now being quite easy to code and compose (using Await and the TAP methods) I am wondering, if we should use async by default and only tune for performance by using sync when needed.

Async I/O frees the calling thread and allows to do something else while waiting for the result. On the other hand async I/O is a little slower than sync.

To enforce responsive UIs the WinRT designers found it acceptable to offer async-only methods.

AFAIK Windows file I/O internally is async. Looking at this naively it is not clear to me, why async file i/O in .NET should be slower than sync at all.

I generally favor simplicity and robustness and only tune for performance where necessary. In the past we used sync by default with the exception of calling some services and where platforms like the phone enforced async. We rarely tuned by using async.

Answer 1

Using async IO has become very easy with C# 5 but there is still a productivity cost associated with it. For example you need to sprinkle new keywords where previously none where necessary. You have to change the return type of your method.

If you decide later that a method should do IO you have to change the entire call chain to switch to async. It is a non-local change spreading to other modules.

You can't profile async IO. Profiling tools pick up nothing. If you pause the debugger nothing is on any of the thread stacks. Nobody seems to be doing anything. That's because an async IO does not hold a thread. It's just a data structure (an object in the kernel).

The decision also depends on the application type. In a WinForms or WPF app I'd rather go with async because it integrates so nicely into the UI thread.

In an ASP.NET/WCF setting the main advantage is that you don't exhaust the thread pool while you call long-running backend services. If you don't have such a problem, and I think this is rather rare, you gain very little from async IO. In fact you loose performance by default.

In a Metro setting the decision has been made for you. Microsoft (legitimately) chose to trade developer productivity for user experience.

So it is not a clear decision. The pros and cons are both quite weak at this point. For that reason I refrain from giving an unambiguous recommendation. It depends very much on the specific case.