Try to reuse initialized generator drivers when we can #80845
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| // HACK: we probably shouldn't have this be a static instance, but this is easier than threading it through from the Workspace layer. | ||
| internal static readonly GeneratorDriverCreationCache Instance = new(); | ||
|
|
||
| private ImmutableDictionary<ProjectId, TaskCompletionSource<GeneratorDriver>> _driverCache = ImmutableDictionary<ProjectId, TaskCompletionSource<GeneratorDriver>>.Empty; |
There was a problem hiding this comment.
Haven't looked at the whole pr, but we rarely cache TCS. We cache AsyncLazy instead.
There was a problem hiding this comment.
Yes we can probably move this on; this changed a bit as I wrote it and since it's draft I didn't give a re-think.
| // There is already some other work in process to create a driver for this project; we'll want to await that work and then | ||
| try | ||
| { | ||
| // TODO: we don't have a WithCancellation() that could be used here, so we should use some alternate pattern to get the |
There was a problem hiding this comment.
I think AsyncLazy would handle that
| { | ||
| data.onAfterUpdate?.Invoke(oldSolution, newSolution); | ||
|
|
||
| newSolution.CompilationState.ClearGeneratorDriverCaches(); |
ToddGrun
reviewed
Oct 22, 2025
...es/Core/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverCreationCache.cs
Outdated
Show resolved
Hide resolved
We're seeing a performnace issue in Razor projects in cohosting scenarios. The first run of the Razor generator is relatively slow, and so ideally we wouldn't have that happen more than once. However, since multiple features might request compilations for a Razor project during startup in parallel, it's possible that all of those parallel invocations might initialize the generator multiple times if they happen to be different Solution instances. This change tries to ensure that when we're creating a GeneratorDriver for a project when we don't already have one, we'll do that computation just once, and try to share that across the forks. This ensures we do the expensive initialization only once.
jasonmalinowski
force-pushed
the
try-to-reuse-initialized-generatordrivers
branch
from
5ce64cf to
931eb2f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We're seeing a performance issue in Razor projects in cohosting scenarios. The first run of the Razor generator is relatively slow, and so ideally we wouldn't have that happen more than once. However, since multiple features might request compilations for a Razor project during startup in parallel, it's possible that all of those parallel invocations might initialize the generator multiple times if they happen to be different Solution instances. This change tries to ensure that when we're creating a GeneratorDriver for a project when we don't already have one, we'll do that computation just once, and try to share that across the forks. This ensures we do the expensive initialization only once.