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

Avoid searching entire trees when looking for implicit constructors in find-refs #73625

Merged
merged 7 commits into from
May 22, 2024

Conversation

CyrusNajmabadi
Copy link
Member

The current approach walks the whole tree for any file that we know has an implicit-object-creation expression in it (e.g. new(...)). This is because we don't know what that expression will bind to, and we have to test each out.

However, walkign the entire tree looking for these is unnecessary. We can instead search the docs containing such nodes for the new tokens in them, and see if they start a new(...) node. This means we only have to walk those small subset of tokens. This addresses about 5% of the cost when doing a FAR on a named-type:

image

@CyrusNajmabadi CyrusNajmabadi requested a review from a team as a code owner May 22, 2024 00:44
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels May 22, 2024
@CyrusNajmabadi CyrusNajmabadi changed the title Search less tokens while finding constructors in find-refs Avoid searching entire trees when looking for implicit constructors in find-refs May 22, 2024
return _identifierCache.GetOrAdd(
identifier,
identifier => FindMatchingIdentifierTokensFromTree(identifier, cancellationToken));
}
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 logic is the smae.

identifier => FindMatchingTokensFromText(
identifier,
static (identifier, token, @this) => @this.IsMatch(identifier, token),
this, cancellationToken));
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 is almost hte same. just the addition of hte lambdaA+args to call nito a unified helper here.

if (!state.Cache.SyntaxTreeIndex.ContainsImplicitObjectCreation)
return;

// Note: only C# supports implicit object creation. So we don't need to do anything special around case
Copy link
Contributor

Choose a reason for hiding this comment

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

So we don't need to do anything special around case

dumb question. If we don't need to worry about VB here, and this is the only caller of GetNewKeywordTokens, why does that code need to worry about VB?

Copy link
Member Author

Choose a reason for hiding this comment

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

it technically doesn't. it was just easier this way.

@CyrusNajmabadi CyrusNajmabadi requested a review from ToddGrun May 22, 2024 03:01
Copy link
Contributor

@ToddGrun ToddGrun left a comment

Choose a reason for hiding this comment

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

:shipit:

@CyrusNajmabadi CyrusNajmabadi enabled auto-merge May 22, 2024 03:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE 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.

3 participants