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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃悋 Avoid generic enumeration in ChecksumCollection.FindAsync #53959

Merged
merged 1 commit into from Jun 22, 2021

Conversation

sharwell
Copy link
Member

@sharwell sharwell commented Jun 8, 2021

@sharwell sharwell requested a review from a team as a code owner June 8, 2021 23:40
internal static async Task FindAsync<TState>(
TextDocumentStates<TState> documentStates,
HashSet<Checksum> searchingChecksumsLeft,
Dictionary<Checksum, object> result,
CancellationToken cancellationToken) where TState : TextDocumentState
{
foreach (var state in documentStates.States)
foreach (var (_, state) in documentStates.States)
Copy link
Member Author

@sharwell sharwell Jun 8, 2021

Choose a reason for hiding this comment

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

馃摑 The generic enumeration was responsible for 89% of the total allocations in searching for assets (10% of the total for the entire VS recording). This fixes a 16.10 regression introduced in #51526.

=> projectState.DocumentStates.States
.Concat(projectState.AdditionalDocumentStates.States)
.Concat(projectState.AnalyzerConfigDocumentStates.States);
=> projectState.DocumentStates.States.Values
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

鉃★笍 This line is the same in this pull request as it was before this pull request. The performance improvement was applied targeting the single hot path method which is now marked with [PerformanceSensitive]. Other methods were optimized where trivial, or left the same.

@@ -83,8 +83,8 @@ public TState GetRequiredState(DocumentId documentId)
/// <summary>
/// States ordered by <see cref="DocumentId"/>.
/// </summary>
public IEnumerable<TState> States
=> _map.Values;
Copy link
Member

Choose a reason for hiding this comment

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

Add ImmutableSortedDictionary.Values to banned APIs?

Copy link
Member

Choose a reason for hiding this comment

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

We could also make this a struct enumerator and keep the callers as they are.

Copy link
Member Author

Choose a reason for hiding this comment

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

Add ImmutableSortedDictionary.Values to banned APIs?

I wouldn't go this far. The PerformanceSensitive attribute is designed with the intent of statically validating this case where it matters.

We could also make this a struct enumerator and keep the callers as they are.

This is a bit difficult. I added these struct enumerators when I wrote ImmutableSortedTreeDictionary<TKey, TValue> but it would be a binary breaking change to incorporate it back into System.Collections.Immutable. See dotnet/runtime#13927 for more details.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I understand we can't update ImmutableSortedTreeDictionary, but we can either create an extension method GetValues(ImmutableSortedTreeDictionary<K,V>) or make specialized struct enumerator just for this property.

@sharwell sharwell changed the title Avoid generic enumeration in ChecksumCollection.FindAsync 馃悋 Avoid generic enumeration in ChecksumCollection.FindAsync Jun 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants