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.

Fantinlatour

The pfxteam blog contain some interesting info in this context: "Please note that we did not add asynchronous versions of APIs that had a very small granularity, such as TextReader.Peek. The reason is that asynchronous APIs also add some overhead and we wanted to prevent developers from accidentally heading in the wrong direction. This also means we specifically decided against providing asynchronous versions for methods on BinaryReader or BinaryWriter.... – Fantinlatour

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.

Thor

Answer 2

I would recommend using async when you have a naturally-asynchronous operation, and synchronous code otherwise. It's true that async is slightly slower, but in most cases it's like "turning up the radio in your Hummer" slower.

In UI programs, async increases responsiveness. In server apps, async increases scalability.

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.

Asynchronous code is slower because it has to allocate structures to track the asynchronous operation; synchronous code just uses the current thread (and its stack). So the operation itself is not slower, but overall there's a slight speed decrease due to more pressure on the garbage collector.

I generally favor simplicity and robustness and only tune for performance where necessary.

I agree. If you have an operation that is naturally asynchronous (such as I/O), expose an async API. And if you have an operation that is naturally synchronous, expose a synchronous API. Stephen Toub has a couple of great blog posts on this (here and here).

Ambivalence