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 pooled array allocations in the SyntaxParser #76610

Merged

Conversation

ToddGrun
Copy link
Contributor

@ToddGrun ToddGrun commented Jan 3, 2025

These pooled array allocations are showing up in the roslyn editing speedometer test as 2.9% of allocations in the code analysis process.

The SyntaxParser has pools for holding the BlendedNode and SyntaxToken arrays it uses. However, it sets the size of the pool to be only 2 items. As these arrays are only released once the parser is disposed, and there are potentially quite a few concurrent parses going on during solution load, there ends up being quite a few allocations of these arrays due to earlier allocations not yet being released to the pool.

Instead, just switch these object pools to use the default for the array size.

Local testing for opening the Roslyn sln showed about 50K SyntaxParser objects constructed, and I was seeing the blended/token arrays allocated 3.5K/10.5K respectively. With this change, I saw those array allocations reduced to 18/54 respectively. Speedometer results look good (images below)

Without change speedometer allocations:
image

With change speedometer allocations:
image

These pooled array allocations are showing up in the roslyn editing speedometer test as 2.9% of allocations in the code analysis process.

The SyntaxParser has pools for holding the BlendedNode and SyntaxToken arrays it uses. However, it sets the size of the pool to be only 2 items. As these arrays are only released once the parser is disposed, and there are potentially quite a few concurrent parses going on during solution load, there ends up being quite a few allocations of these arrays due to earlier allocations not yet being released to the pool.

Instead, just switch these object pools to use the default for the array size.

Local testing for opening the Roslyn sln showed about 50K SyntaxParser objects constructed, and I was seeing the blended/token arrays allocated 3.5K/10.5K respectively. With this change, I saw those array allocations reduced to 18/54 respectively. Will create a test insertion to get speedometer numbers.
@ToddGrun ToddGrun requested a review from a team as a code owner January 3, 2025 16:51
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Jan 3, 2025
Copy link
Contributor

@AlekseyTs AlekseyTs left a comment

Choose a reason for hiding this comment

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

LGTM (commit 1)

@ToddGrun ToddGrun merged commit 978be80 into dotnet:main Jan 4, 2025
24 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Jan 4, 2025
checkedsums pushed a commit to checkedsums/roslynjourneys that referenced this pull request Jan 5, 2025
These pooled array allocations are showing up in the roslyn editing speedometer test as 2.9% of allocations in the code analysis process.

The SyntaxParser has pools for holding the BlendedNode and SyntaxToken arrays it uses. However, it sets the size of the pool to be only 2 items. As these arrays are only released once the parser is disposed, and there are potentially quite a few concurrent parses going on during solution load, there ends up being quite a few allocations of these arrays due to earlier allocations not yet being released to the pool.

Instead, just switch these object pools to use the default for the array size.

Local testing for opening the Roslyn sln showed about 50K SyntaxParser objects constructed, and I was seeing the blended/token arrays allocated 3.5K/10.5K respectively. With this change, I saw those array allocations reduced to 18/54 respectively. Will create a test insertion to get speedometer numbers.
@dibarbet dibarbet modified the milestones: Next, 17.13 P3 Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants