Try to reuse initialized generator drivers when we can#80845
Conversation
...es/Core/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverCreationCache.cs
Outdated
Show resolved
Hide resolved
...es/Core/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverCreationCache.cs
Outdated
Show resolved
Hide resolved
...es/Core/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverCreationCache.cs
Outdated
Show resolved
Hide resolved
5ce64cf to
931eb2f
Compare
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.
931eb2f to
61ac7f7
Compare
...e/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverInitializationCache.cs
Show resolved
Hide resolved
...e/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverInitializationCache.cs
Show resolved
Hide resolved
...e/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverInitializationCache.cs
Show resolved
Hide resolved
src/Workspaces/Core/Portable/Workspace/Solution/SolutionCompilationState.cs
Show resolved
Hide resolved
| // for it -- we can potentially reuse a GeneratorDriver created for another instance (after we update it to match.) The | ||
| // assumption here is by the time we're updating the CurrentSolution to point to a projects that have GeneratorDrivers, | ||
| // we won't need that cache anymore since any further requests for generated documents will use the properly held GeneratorDriver. | ||
| data.@this.GeneratorDriverCreationCache.EmptyCacheForProjectsThatHaveGeneratorDriversInSolution(newSolution.CompilationState); |
There was a problem hiding this comment.
i will admit that i haven't figure out what this comment means.
There was a problem hiding this comment.
I've give another attempt at a rewrite. (I say "another" only because there's a few unpushed versions that I really hated too...)
There was a problem hiding this comment.
ok. one final request. can you update the comment here to make it clear that this could mean we're dumping a driver that some forked could beneffit from. but that's ok as we're just trying to benefit some common scenarios, and we don't want to hold onto things forever. so we prefer keepign the cache clear once we feel it's likely served its purpose (or something like that).
There was a problem hiding this comment.
Will update after merge to keep this moving.
cc64b3b to
18775a6
Compare
...e/Portable/Workspace/Solution/SolutionCompilationState.GeneratorDriverInitializationCache.cs
Show resolved
Hide resolved
|
/backport to release/dev18.3 |
|
Started backporting to |
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.