Sync vs Async File I/O in .NET: Raw Throughput, Scalability, and Buffer Size

This post is part of the series 'Async/await in C#'. Be sure to check out the rest of the blog posts of the series!

• Why async exists: the cost of blocking a thread
• There is no thread: OS async I/O and the .NET thread pool
• The Task lifecycle and TaskCompletionSource
• The awaitable pattern: writing your own awaitable
• How the C# compiler rewrites an async method
• Writing your own Task from scratch
• Writing your own CancellationToken from scratch
• Async method builders and where the allocations go
• ExecutionContext: what flows across an await
• SynchronizationContext ConfigureAwait and deadlocks
• Task vs ValueTask and IValueTaskSource
• Async streams: IAsyncEnumerable and await foreach
• IAsyncDisposable and await using
• Cancellation: CancellationToken end to end
• Composing async work: WhenAll WhenAny and WhenEach
• Synchronization in async code: lock and SemaphoreSlim
• Prefer async/await over directly returning Task
• The cost of async: a BenchmarkDotNet study on .NET 10
• .NET 11 runtime async: the runtime takes over await
• Runtime async benchmarks: .NET 10 vs .NET 11
• Migrating to runtime async
• Sync vs Async File I/O in .NET: Raw Throughput, Scalability, and Buffer Size (this post)

The default recommendation for .NET is to prefer async file I/O for scalability. That is generally good advice. However, there are cases where sync file I/O can be faster. If you desktop application loads multiple files during startup, synchronous IO can make you application feel more snappy.

That does not mean async is bad. It means sync and async optimize for different goals:

• Use sync I/O when you care about fastest single-operation latency, such as loading data during application startup.
• Use async I/O when you care about scalability and thread availability under concurrent workloads.

#Async File I/O

Async I/O is designed to allow other work to proceed while waiting for I/O operations to complete. This can improve scalability and responsiveness in scenarios with many concurrent operations, such as web servers or applications that perform background processing.

However, async I/O introduces overhead from task scheduling, state machines, and continuations. For small or moderate reads, that overhead can dominate the total time, making async appear slower in raw benchmarks.

Note that async I/O must be enabled at the stream level to achieve true asynchronous behavior.. If you call async APIs on a stream not configured for async, the runtime may fall back to a less efficient path. In practice, that means you must use the FileOptions.Asynchronous flag when opening the stream:

await using var stream = new FileStream(
    path,
    FileMode.Open,
    FileAccess.Read,
    FileShare.Read,
    bufferSize: 64 * 1024,
    options: FileOptions.Asynchronous);

var buffer = new byte[64 * 1024];
var readCount = await stream.ReadAsync(buffer);

#Buffer Size Is a First-Class Tuning Knob

The benchmark also shows that buffer size can move results significantly. For many sequential workloads, a moderate-to-large buffer such as 64 KB often gives a good balance:

• It reduces syscall overhead compared to tiny buffers.
• It avoids the extra memory pressure and allocation cost of very large buffers.

There is no universal best value. Benchmark your own workload, but do not leave buffer size as an afterthought.

#Sequential Reads Should Use SequentialScan

When reading from start to end without seeks, FileOptions.SequentialScan is usually a good hint to the OS cache manager. Sequential reads are common in scenarios like loading a configuration files.

using var stream = new FileStream(
    path,
    FileMode.Open,
    FileAccess.Read,
    FileShare.Read,
    bufferSize: 64 * 1024,
   options: FileOptions.SequentialScan);

For async sequential reads, combine both flags:

options: FileOptions.Asynchronous | FileOptions.SequentialScan

#Benchmark

##File.ReadAllBytes benchmark

##SequentialRead / Buffer size benchmark

SequentialRead is not always faster. When it is not faster, the values are very close. Also, benchmark on the file system is not very stable. The takeaway is that you should benchmark with realistic file sizes and concurrency levels, not microbenchmarks only.

#Practical Rules

Use these defaults unless profiling proves otherwise:

1. Startup path, single file, latency-sensitive: prefer sync.
2. High concurrency server code: prefer async to avoid blocking worker threads.
3. If you call ReadAsync or WriteAsync, open the stream with FileOptions.Asynchronous.
4. For full-file sequential scans, test with FileOptions.SequentialScan.
5. Benchmark with realistic file sizes and concurrency levels, not microbenchmarks only.

Choosing sync vs async is not about ideology. It is about matching the I/O model to the workload.

##Additional resources

• Synchronous and Asynchronous I/O (Windows docs)
• FileStream class (.NET docs)

Do you have a question or a suggestion about this post? Contact me!