Improve GreenNode.ToString() implementation for efficiency#12344
Merged
DustinCampbell merged 9 commits intoOct 20, 2025
Conversation
- Remove #nullable disable and add a couple of annotations. - Convert a couple of properties to expression-bodied properties. - Update ChildSyntaxList and SyntaxNode to account for nullability.
- Remove #nullable disable and add a couple of annotations.
- Add IsEmpty property to MemoryBuilder<T> - Add Push(), Peek(), Pop, and TryPop() methods to MemoryBuilder<T> - Change AsMemory() to return a Memory<T> rather than a ReadOnlyMemory<T>. - Mark indexer as read only. - Add unit tests.
Add GreenNode.GetEnumerator() method that returns a ref struct-based Enumerator to perform a depth-first traversal using the target GreenNode as the root. SyntaxList nodes are transparent and not returned from the enumerator. Unit tests are included along with some helpers to make constructing GreenNodes a bit easier. The helpers include: - A handful of SyntaxFactory methods to avoid passing extra arguments. - A [CollectionBuilder] attribute for SyntaxList<TNode> - SyntaxList.Create(...) methods for the [CollectionBuilder] to target.
Add GreenNode.Tokens() method that returns a TokenEnumerable, a ref struct that provides a GetEnumeartor() that returns a ref struct-based Enumerator to perform a depth-first traversal that returns SyntaxToken instances. Unit tests for Tokens() and TokenEnumerable.GetEnumerator() have been added.
This change removes the StringWriter machinery from GreenNode. It only adds overhead. In its place is a more efficient implementation using string.Create. This avoids copying the characters into a StringWriter and then allocating a new string from the writer, which copies all of the characters *again* into a new string. Because we know the width of a GreenNode, we know the length of the string it will produce.
string.Build(...) collects "chunks" of text as ReadOnlyMemory<char>s before creating a string from them. This ensures that characters are not copied to a buffer and copied again when allocating the final string.
ToddGrun
reviewed
Oct 16, 2025
ToddGrun
reviewed
Oct 16, 2025
1. GetDebuggerDisplay should just return an interpolated string. (Oops!) 2. ToString should implement two specific optimizations to avoid allocating a new string unless necessary. - If the width is zero, return string.Empty. - If there is just a single non-zero-width token with the same width as the node, just return that token's content.
ToddGrun
reviewed
Oct 16, 2025
ToddGrun
reviewed
Oct 16, 2025
davidwengier
approved these changes
Oct 16, 2025
Member
Author
|
@chsienki: I'm going to go ahead and merge this compiler. Please let me know if you have any concerns. |
This was referenced Oct 21, 2025
This was referenced Oct 23, 2025
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Tip
I recommend reviewing this PR commit-by-commit. Each commit represents a concrete change and includes a description.
The key improvement in this change is to take advantage of the fact that a green node's width is the same as the length of the string produced by
ToString(). So, we can use the width to callstring.Create(...)and efficiently create the string rather than building it up with aStringWriter.Using a
StringWriterrequires all of the characters to first be copied into the writer's underlyingStringBuilderand then copy them again when creating the final string. We can avoid this extra copying by usingstring.Create(...)and copying the characters directly into the final string. The end result is a simpler implementation that avoids the need for aStringWriterpool.CI Build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2817951&view=results
Test Insertion: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/680209
Toolset Run: https://dev.azure.com/dnceng/internal/_build/results?buildId=2817952&view=results