-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce StreamWriter allocation #44495
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GrabYourPitchforks
approved these changes
Nov 10, 2020
jkotas
reviewed
Nov 10, 2020
src/libraries/System.Private.CoreLib/src/System/IO/StreamWriter.cs
Outdated
Show resolved
Hide resolved
EgorBo
reviewed
Nov 10, 2020
jozkee
approved these changes
Nov 11, 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise; LGTM.
src/libraries/System.Private.CoreLib/src/System/IO/StreamWriter.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/IO/StreamWriter.cs
Outdated
Show resolved
Hide resolved
The byte[] buffer is used just when flushing to the underlying stream, to store the intermediate bytes as generated from the characters by the encoding. Currently the byte[] buffer is allocated in the constructor, but for relatively small strings written/flushed synchronously (such as those often used with Console.Write), we can avoid the buffer entirely via stack allocation (in Flush); for all other cases, we can allocate it on demand. (I considered using ArrayPool to rent/return in each Flush{Async} call, but opted not to in this change. Someone could investigate that subsequently.)
In .NET Framework, there was a non-trivial penalty due to StreamWriter deriving from MarshalByRefObject and the impact that had on async methods accessing lifted locals on the state machine (it made them significantly more expensive). The workaround was to make the async methods be statics and pass in all of the relevant instance state needed. That workaround is no longer necessary on core, where MarshalByRefObjects are nops, leaving behind a workaround that is not just clunkier, but actually makes things more expensive because more state needs to be stored on the state machine objects (all of the arguments, which can instead just be accessed off of `this`). Undo that whole change.
stephentoub
force-pushed
the
streamwriterbuffer
branch
from
November 11, 2020 02:11
b868fac
to
d15f8be
Compare
This was referenced Nov 11, 2020
ghost
locked as resolved and limited conversation to collaborators
Dec 12, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Two changes:
Contributes to #44598