Skip to content

Cache MEF catalog in servicehub process #78122

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

Conversation

ToddGrun
Copy link
Contributor

@ToddGrun ToddGrun commented Apr 11, 2025

Cache the MEF catalog created in the roslyn code analysis process.

On my dev machine, the creation of the MEF catalog in our CA process takes about 500 ms. With this change, runs that were able to load from the cache saw that time reduced to about 150 ms.

The high-level change here is to piggy back on the work that Joey did a while back to add MEF catalog caching to our VSCode language server. This PR just moves that code down to a layer where our service hub code can reference, and generalized it a bit to fit into what the service hub code can provide.

One slight additional change in this PR was to add a new remote service to handle passing over the proper location to store the mef cache. I didn't feel comfortable fitting this into the previous first message sent across (IRemoteProcessTelemetryService), so I created IRemoteInitializationService to better fit what I wanted. This led to creating a separate type to handle the export provider creation (RemoteExportProvider) instead of tying this up into RemoteWorkspaceManager.

@ghost ghost added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 11, 2025
@ToddGrun ToddGrun changed the title *** WIP: Cache MEF catalog in servicehub process Cache MEF catalog in servicehub process Apr 11, 2025
@ToddGrun ToddGrun marked this pull request as ready for review April 11, 2025 21:30
@ToddGrun ToddGrun requested review from a team as code owners April 11, 2025 21:30
Copy link
Member

@dibarbet dibarbet left a comment

Choose a reason for hiding this comment

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

Someone else should likely review the servicehub initialization part

switch to record struct for args encapsulation
2) Add new expected error'ed type in CA process MEF composition
Resolver: new Resolver(SimpleAssemblyLoader.Instance),
CacheDirectory: Path.Combine(localSettingsDirectory, "Roslyn", "RemoteHost", "Cache"),
CatalogPrefix: "RoslynRemoteHost",
ExpectedErrorParts: ["PythiaSignatureHelpProvider", "VSTypeScriptAnalyzerService", "RazorTestLanguageServerFactory", "CodeFixService"],
Copy link
Contributor Author

Choose a reason for hiding this comment

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

"CodeFixService"

@CyrusNajmabadi -- any idea why this type has started not resolving in the CA process MEF composition?

Copy link
Member

Choose a reason for hiding this comment

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

Is that some fallout of the recent removal of EditorFeatures? That was rolled back, but it's still suspicious.

Copy link
Contributor Author

@ToddGrun ToddGrun Apr 16, 2025

Choose a reason for hiding this comment

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

I merged main and this type still errors.

Microsoft.CodeAnalysis.CodeFixes.CodeFixService.ctor(diagnosticAnalyzerService): expected exactly 1 export matching constraints:
    Contract name: Microsoft.CodeAnalysis.Diagnostics.IDiagnosticAnalyzerService
    TypeIdentityName: Microsoft.CodeAnalysis.Diagnostics.IDiagnosticAnalyzerService
but found 0.

Copy link
Member

Choose a reason for hiding this comment

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

my pr hasn't merged in yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I tested with both our branches combined and it gets rid of the errors for VSTypeScriptAnalyzerService and CodeFixService

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here are the errors for those two:

Microsoft.CodeAnalysis.ExternalAccess.Razor.RazorTestLanguageServerFactory.ctor(languageServerFactory): expected exactly 1 export matching constraints:
    Contract name: Microsoft.CodeAnalysis.LanguageServer.ILanguageServerFactory
    TypeIdentityName: Microsoft.CodeAnalysis.LanguageServer.ILanguageServerFactory
but found 0.

Microsoft.CodeAnalysis.ExternalAccess.Pythia.PythiaSignatureHelpProvider.ctor(implementation): expected exactly 1 export matching constraints:
    Contract name: Microsoft.CodeAnalysis.ExternalAccess.Pythia.Api.IPythiaSignatureHelpProviderImplementation
    TypeIdentityName: Microsoft.CodeAnalysis.ExternalAccess.Pythia.Api.IPythiaSignatureHelpProviderImplementation
but found 0.

Copy link
Member

Choose a reason for hiding this comment

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

woot.

@ToddGrun
Copy link
Contributor Author

ToddGrun commented Apr 15, 2025

Someone else should likely review the servicehub initialization part

@jasonmalinowski -- ptal

@ToddGrun
Copy link
Contributor Author

Test insertion doesn't show any regressions: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/629927

2) Add comment around IO exception expectations
3) Change AddRange => Add call
? Path.Combine(thisAssemblyFolder, assemblySimpleName + ".dll")
: null;

if (File.Exists(potentialAssemblyPath))
Copy link
Member

Choose a reason for hiding this comment

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

doc IO strategy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think File.Exists exposes IO failures

2) Tuples are camel cased (blech)
3) Comment IO exception strategy
4) Use threading context in call to ServiceHubRemoteHostClient.CreateAsync
@ToddGrun ToddGrun merged commit 409b86c into dotnet:main Apr 22, 2025
28 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Apr 22, 2025
davidwengier added a commit that referenced this pull request Apr 24, 2025
#78122 broke Razor tests, because
we now have to initialize the export provider builder first.
Initializing the export provider builder broke Razor tests, because I
had an old copy of the EA dll laying around
Fixing the name of the EA dll broke Razor tests, because of a MEF
composition error with the RazorTestLanguageServerFactory
And thats how we got here.
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 VSCode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants