Win32 FileStream will issue a seek on every ReadAsync call

[ayende]

Full description is here:
https://ayende.com/blog/173345/the-cost-of-async-i-o?key=227b21e219594be48ca03bc8312b08b9

But the gist of it is that we are trying to call ReadAsync on a file that is located on a remote share.
Using ReadAsync, we saw a really horrible performance degradation.

We tracked it down to this issue:

And here is the problematic code:
https://github.com/dotnet/corefx/blob/master/src/System.IO.FileSystem/src/System/IO/Win32FileStream.cs#L1201

Given that all async calls are always passing the position they use in the overlap, and how expensive this call is, it make for a very bad combination.

[stephentoub]

cc; @ericstj, @ianhays. @JeremyKuhne

[ericstj]

The uber problem here is that FileStream's contract is to update the Length and Position as part completing the synchronous portion of the Read. Folks are seeing the same sorts of problems on Writes where we call setlength before the write.

The fix here is to change that contract. If FileStream kept track of it's own Length and Position in the case of an async handle and was less aggressive about making sure the handle was in sync we'd fix these perf issues. The downside is that this changes the externally observable behavior of the file/handle (if shared) so we'd need to quirk it.

[ayende]

Why do you need to change the contract?
You can do that only if the handle is shared. If the handle isn't shared, you know that no one is going to look at its state, so you don't need to update it.

The code is already tracking this:
https://github.com/dotnet/corefx/blob/master/src/System.IO.FileSystem/src/System/IO/Win32FileStream.cs#L54

If _exposedHandle is false, there is no need to set the handle's values.

[ericstj]

I was referring more to the write side of this bug. The length of the file is observable from an external process.

[ayende]

Still the same thing, though. It is the OS responsibility to update the file length if the file length changed.

What is the scenario where an external process require you to set the file pointer if the handle isn't available externally?

[ericstj]

It is the OS responsibility

Ideally yes, but we set a precedent in desktop otherwise (set length before write), thus the need to be careful about this fix. I'm not saying we don't do this, just saying we need to be careful about existing externally observable behavior.

[omariom]

seek() + write() vs pwrite()
though not on Windows.

[ayende]

My test was run on Windows.
Both the source machine and the network drive are windows machines.

*Hibernating Rhinos Ltd *

Oren Eini* l CEO l *Mobile: + 972-52-548-6969

Office: +972-4-622-7811 *l *Fax: +972-153-4-622-7811

On Fri, Feb 12, 2016 at 7:03 PM, OmariO notifications@github.com wrote:

seek() + write() vs pwrite()
https://www.lmax.com/blog/staff-blogs/2015/07/03/seek-write-vs-pwrite/
though not on Windows.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/corefx/issues/6039#issuecomment-183413646.

[jgowdy]

@omariom You can simulate pwrite on Windows by using WriteFile with an OVERLAPPED structure with hEvent set to 0, and the 64bit file pointer set via Offset and OffsetHigh.