FileStream.BeginWrite advantages over FileStream.Write?

Question

I need to make a batch of writes to the same file but at different places within the file. I want to achieve this with the best performance possible and so have looked at the synchronous FileStream.Write and asynchronous FileStream.BeginWrite methods.

A synchronous implemention is trivial and simply calls the FileStream.Write the required number of times in a loop. The async version calls FileStream.BeginWrite in a loop and then does a WaitHandle.WaitAll in order to block until they have all completed. To my surprise this works slower than the simple synchronous version.

I have created the FileStream using the correct constructor so I can request async operation and I also tested the IAsyncResult.CompletedSynchronous property which indicated False and so they did indeed operate in an async fashion. It seems that the only benefit from using BeginWrite is that you are not blocking your thread whilst the write occurs. Apart from this benefit is there any point in using the async version?

Here is the test code I used for playing with the async method, maybe there is an obvious error?

        // Size of a chunk to be written to file
        var chunk = 1024 * 64;

        // Number of chunks to write async
        var reps = 32;

        // Create new file and set length
        var fs = new FileStream(@"C:\testfile.dat", 
                                FileMode.Create, FileAccess.ReadWrite, 
                                FileShare.None, chunk, true);
        fs.SetLength(chunk * reps);

        // Allocate resources
        byte[] bytes = new byte[chunk];
        WaitHandle[] handles = new WaitHandle[reps];

        for (int i = 0; i < reps; i++)
        {
            fs.Seek(chunk * i, SeekOrigin.Begin);
            handles[i] = fs.BeginWrite(bytes, 0, chunk, null, null).AsyncWaitHandle;
        }

        // Wait for all async operations to complete
        WaitHandle.WaitAll(handles);

        fs.Flush();
        fs.Close();

Answer 1

File writes are heavily optimized in Windows. You don't actually write to the disk, you write to the file system cache. A memory-to-memory copy, runs at 5 gigabytes per second or better. From the cache, the data is then lazily written to disk. In turn optimized to minimize the number of write head moves.

This is next to impossible to optimize with asynchronous writes. Which do indeed take longer, grabbing the threadpool thread to make the callback doesn't come for free. The benefit of async here is minimizing the main thread delays, not to actually make it more efficient. You will only actually get the benefit when you write very large amounts of data. More than will fit into the cache. At that point, write perf will fall off a cliff from 5 GB/sec to less than ~50 MB/sec since cache space can only become available at the rate the disk can be written.

Exactly when that happens is hard to predict. It depends how much RAM the machine has and how much of it is needed by other processes. You basically don't worry about it when you write a gigabyte or less. And it is important that you actually have something useful to do when the async write is pending. Waiting for them to complete defeats the point of using it.