Skip to content
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 3 commits into from
Nov 11, 2020

Conversation

stephentoub
Copy link
Member

@stephentoub stephentoub commented Nov 10, 2020

Two changes:

  1. Lazily-allocate StreamWriter's byte[] buffer. If the StreamWriter is only ever used for synchronous writing of small payloads, e.g. a typical Console.WriteLine scenario, then it won't ever allocate its byte[] buffer. This relates to Remove some allocation at "hello world" startup #44469, in that one of the byte[] arrays shown there is removed.
  2. Undo use of static async helpers. For legacy reasons, the async methods were wrapping static helpers and passing in all relevant instance state as arguments to those helpers. This in turn bloats the size of those state machines, in addition to complicating the code / maintainability.

Contributes to #44598

@stephentoub stephentoub added area-System.IO tenet-performance Performance related issue labels Nov 10, 2020
@stephentoub stephentoub added this to the 6.0.0 milestone Nov 10, 2020
Copy link
Member

@jozkee jozkee left a comment

Choose a reason for hiding this comment

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

Otherwise; LGTM.

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 stephentoub merged commit 33c9d5a into dotnet:master Nov 11, 2020
@stephentoub stephentoub deleted the streamwriterbuffer branch November 11, 2020 10:23
@ghost 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.
Labels
area-System.IO tenet-performance Performance related issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants