Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Use UnixFileStream's ReadAsync implementation on Windows when !IsAsync#56682

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
adamsitnik merged 1 commit intodotnet:mainfromstephentoub:consolidatefslogic
Aug 2, 2021

Conversation

@stephentoub
Copy link
Member

UnixFileStream's ReadAsync implementation uses a reusable IValueTaskSource implementation to avoid allocating a new work item on every read. We can push that implementation down to OSFileStreamStrategy, and then use it for the Windows implementation of ReadAsync as well when IsAsync==false, rather than delegating to the base Stream implementation.

This PR almost entirely just moves code around. The only change to logic is in RandomAccess.Windows.cs, to only set an offset into the NativeOverlapped if the SafeFileHandle is seekable; otherwise, it fails when used with pipes.

MethodToolchainMeanErrorStdDevRatioGen 0Allocated
Read\main\corerun.exe36.19 ms0.568 ms0.531 ms1.00-31 B
Read\pr\corerun.exe35.71 ms0.296 ms0.263 ms0.99-34 B
ReadAsync\main\corerun.exe45.84 ms0.360 ms0.337 ms1.0090.90911,094,165 B
ReadAsync\pr\corerun.exe42.74 ms0.434 ms0.406 ms0.93-256 B
privatebyte[]_buffer=newbyte[4096];privateFileStream_stream;[GlobalSetup]publicvoidSetup(){byte[]bytes=newbyte[40_000_000];newRandom().NextBytes(bytes);stringpath=Path.GetTempFileName();File.WriteAllBytes(path,bytes);_stream=File.OpenRead(path);}[GlobalCleanup]publicvoidCleanup(){_stream.Close();File.Delete(_stream.Name);}[Benchmark]publicvoidRead(){_stream.Position=0;while(_stream.Read(_buffer)!=0);}[Benchmark]publicasyncTaskReadAsync(){_stream.Position=0;while(await_stream.ReadAsync(_buffer)!=0);}

cc:@adamsitnik

UnixFileStream's ReadAsync implementation uses a reusable IValueTaskSource implementation to avoid allocating a new work item on every read.  We can push that implementation down to OSFileStreamStrategy, and then use it for the Windows implementation of ReadAsync as well when IsAsync==false, rather than delegating to the base Stream implementation.This PR almost entirely just moves code around.  The only change to logic is in RandomAccess.Windows.cs, to only set an offset into the NativeOverlapped if the SafeFileHandle is seekable; otherwise, it fails when used with pipes.
@stephentoubstephentoub added area-System.IO tenet-performancePerformance related issue labelsAug 1, 2021
@stephentoubstephentoub added this to the6.0.0 milestoneAug 1, 2021
@ghost
Copy link

Tagging subscribers to this area: @dotnet/area-system-io
See info inarea-owners.md if you want to be subscribed.

Issue Details

UnixFileStream's ReadAsync implementation uses a reusable IValueTaskSource implementation to avoid allocating a new work item on every read. We can push that implementation down to OSFileStreamStrategy, and then use it for the Windows implementation of ReadAsync as well when IsAsync==false, rather than delegating to the base Stream implementation.

This PR almost entirely just moves code around. The only change to logic is in RandomAccess.Windows.cs, to only set an offset into the NativeOverlapped if the SafeFileHandle is seekable; otherwise, it fails when used with pipes.

MethodToolchainMeanErrorStdDevRatioGen 0Allocated
Read\main\corerun.exe36.19 ms0.568 ms0.531 ms1.00-31 B
Read\pr\corerun.exe35.71 ms0.296 ms0.263 ms0.99-34 B
ReadAsync\main\corerun.exe45.84 ms0.360 ms0.337 ms1.0090.90911,094,165 B
ReadAsync\pr\corerun.exe42.74 ms0.434 ms0.406 ms0.93-256 B
privatebyte[]_buffer=newbyte[4096];privateFileStream_stream;[GlobalSetup]publicvoidSetup(){byte[]bytes=newbyte[40_000_000];newRandom().NextBytes(bytes);stringpath=Path.GetTempFileName();File.WriteAllBytes(path,bytes);_stream=File.OpenRead(path);}[GlobalCleanup]publicvoidCleanup(){_stream.Close();File.Delete(_stream.Name);}[Benchmark]publicvoidRead(){_stream.Position=0;while(_stream.Read(_buffer)!=0);}[Benchmark]publicasyncTaskReadAsync(){_stream.Position=0;while(await_stream.ReadAsync(_buffer)!=0);}

cc:@adamsitnik

Author:stephentoub
Assignees:-
Labels:

area-System.IO,tenet-performance

Milestone:6.0.0

Copy link
Member

@adamsitnikadamsitnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM, thank you@stephentoub !

returnMemoryMarshal.TryGetArray(buffer,outArraySegment<byte>segment)?
newValueTask(BeginWriteInternal(segment.Array!,segment.Offset,segment.Count,null,null,serializeAsynchronously:true,apm:false)):
base.WriteAsync(buffer,cancellationToken);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

after this code removal,SyncWindowsFileStreamStrategy andUnixFileStreamStrategy become de facto classes that do not change or extend the behaviour ofOSFileStreamStrategy.

Have you considered the removal ofSyncWindowsFileStreamStrategy andUnixFileStreamStrategy and usingOSFileStreamStrategy directly?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

No strong opinion. If you'd like to consolidate, go for it. If not, I'm ok keeping the derived types.

@adamsitnik
Copy link
Member

I am going to merge it now so I can get updated numbers for the blog post ;)

@adamsitnikadamsitnik merged commit79c4144 intodotnet:mainAug 2, 2021
@adamsitnik
Copy link
Member

I am not sure if this was intentional, but after moving all the logic fromUnix toOS strategy it's now much easier to work with the code on Windows. Refactoring in VS renames all usages of methods, and it's less likely for the code to compile fine on Windows and fail on Unix. 👍

stephentoub reacted with thumbs up emoji

@stephentoubstephentoub deleted the consolidatefslogic branchAugust 2, 2021 10:50
@ghostghost locked asresolvedand limited conversation to collaboratorsSep 1, 2021
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.

Reviewers

@adamsitnikadamsitnikadamsitnik approved these changes

Assignees

No one assigned

Labels

area-System.IOtenet-performancePerformance related issue

Projects

None yet

Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

2 participants

@stephentoub@adamsitnik

[8]ページ先頭

©2009-2025 Movatter.jp