Skip to content

Conversation

@ToddGrun
Copy link
Contributor

@ToddGrun ToddGrun commented Sep 9, 2025

Instead of realizing ImmutableArrays in several codepaths, we can instead just have the calculations append items to an existing list.

Also, in ConvertSemanticRangesToSemanticTokensData, switches to optimistically allocating an int[] instead of a pooled list for two reasons:

  1. In almost all cases, the correct size is calculated before population
  2. The pooled list that was being created commonly ended up being too large to be placed back in the pool, so we would end up losing both that list and it's backing array to GC.

This wasn't a huge memory hitter for me in the profile I'm looking at, but still is ~0.6% of allocations in the RoslynCodeAnalysisService process during the C#/html completions in the razor cohosting speedometer test.

Test insertion: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/669091

Numbers looked good in the test insertion: SemanticRange[] allocations pretty much gone, and the int[] allocations in ConvertSemanticRangesToSemanticTokensData are down significantly too.

Instead of realizing ImmutableArrays in several codepaths, we can instead just have the code append the new items to an existing list.

Also, in ConvertSemanticRangesToSemanticTokensData, switches to optimistically allocating an int[] instead of a pooled list for two reasons:

1) In almost all cases, the correct size is calculated before population
2) The pooled list that was being created ended up being too large to be placed back in the pool, so we ended up losing both that list and it's backing array to GC.
@ToddGrun ToddGrun requested a review from a team as a code owner September 9, 2025 23:23
Copy link
Member

@davidwengier davidwengier left a comment

Choose a reason for hiding this comment

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

Other than the build errors and some naming tweaks, this makes sense to me.

@ToddGrun
Copy link
Contributor Author

Test insertion run from commit 4 didn't have expected gains. Looks like the test is using a larger page than I was testing against. Switched to a custom pool which should work better against larger sematic token request. Test insertion queued for new numbers.

@ToddGrun
Copy link
Contributor Author

@DustinCampbell -- I think I liked every single suggestion you made! Thanks!

Copy link
Member

@DustinCampbell DustinCampbell left a comment

Choose a reason for hiding this comment

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

🚀

@ToddGrun ToddGrun merged commit 3510452 into dotnet:main Sep 11, 2025
11 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Sep 11, 2025
@akhera99 akhera99 modified the milestones: Next, 18.0 P1, 18.0 P2 Sep 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants