dotnet-issue-labeler[bot]
commented
3 years ago I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
Closed fitdev closed 3 years ago
dotnet-issue-labeler[bot]
commented
3 years ago I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
jaredpar
commented
3 years ago Moving to dotnet/runtime as it appears to be an issue with the Json source generator.
@chsienki for monitoring as this may be a case where we can leverage the V2 APIs for IDE perf
ghost
commented
3 years ago Tagging subscribers to this area: @eiriktsarpalis, @layomia See info in area-owners.md if you want to be subscribed.
| Author: | fitdev |
|---|---|
| Assignees: | - |
| Labels: | `area-System.Text.Json`, `untriaged` |
| Milestone: | - |
layomia
commented
3 years ago @fitdev thanks for the feedback. We should minimize the amount of work done when the generator is present but there are no indicated serializable types, and also to make the execution of the generator as efficient as possible when there are types to generate code for. As a starting point - we are currently doing a lot of expensive type resolution every time the generator runs. We should defer this work until we are sure that there are types indicated for source generation, and also cache these type references for reuse whenever possible. One thought here is to observe the compilation instance, and if it's the same as the last one, we reuse some of the relevant metadata that we've computed previously. I'm currently prototyping this approach and will make a PR soon.
As already mentioned we should also consider whether the v2 source generator APIs can help with some of these IDE perf considerations.
Also note that my solution does NOT use any source generators. And VS's option Text Editor > VB/C# > Advanced > Enable all features in opened files from source generators (experimental) is tuned OFF.
This suggests that we might have a scenario in VS where the source generators are invoked even when users explicitly opt out of using them. @chsienki, @KathleenDollard do we have settings specifying this behavior? I wasn't able to find any using Visual Studio Enterprise 2019 16.10.0 Preview 2.1.
Can you provide a sample project to repro the issues you are facing here (sanitized if necessary)? This can help us further understand the issue here and help validate the fixes. Please include any further information about any configuration for your solution(s) & projects.
sharwell
commented
3 years ago @layomia It's extremely difficult to implement source generator caching in a way that is compatible with the semantics of the v1 (non-incremental) API. If the source generator contains a syntax receiver, this task should be treated as impossible; the source generator will not scale to large projects without migration to the v2 (incremental) API. There are two potential resolutions here:
layomia
commented
3 years ago Migrate to the v2 API
Thanks @sharwell. I'll start planning for this. I consider this a .NET 6 effort since we want the source generator to be usable in IDE scenarios. cc @ericstj
Update: before committing to reimplementing the generator with v2 APIs at this stage in .NET 6, I think it's better for me to first quantify how bad the problem is and what type of improvements we could see by just refactoring as I mentioned earlier.
ericstj
commented
3 years ago @maryamariyan as it looks like the logging generator has a similar pattern.
fitdev
commented
3 years ago Please include any further information about any configuration for your solution(s) & projects.
@layomia Thank you for looking into this. Unfortunately I cannot provide even a sanitized solution for a repro, as it would involve several 1000 files. Basically I see this behavior with medium-large solutions. As I said, most of my projects are C#, some VB, using latest NET6 Preview 6 and latest VS 2022.
I would eventually like to utilize JSON source generators of course, so it is a great effort, but not until such serious performance issues are addressed. And in any case there hsould be away to completely turn off the feature - either at the IDE level and/or at the project level via something like <EnableFrameworkSourceGenerators>false</EnableFRameworkSourceGenerators>, or perhaps even allowing one to specify specifically which source generators should be enabled (since you also have a Logging source generator - and that only for NET 6): <SourceGeneratorNamespaces>System.Text.Json;Logging;etc.</SourceGeneratorNamespaces>.
ericstj
commented
3 years ago You can add a target to Directory.Build.Targets in your repo to workaround this:
<Target Name="_RemoveTextJsonAnalyzer" BeforeTargets="CoreCompile">
<ItemGroup>
<Analyzer Remove="@(Analyzer)" Condition="'%(FileName)' == 'System.Text.Json.SourceGeneration'" />
</ItemGroup>
</Target>CC @russkie as well for winforms generators with SyntaxReceivers
layomia
commented
3 years ago We discussed a plan offline to mitigate the perf regression here. Here's a summary of the current thinking:
Concrete next steps for .NET 6:
fitdev
commented
3 years ago Identify a way to granularly disable source generators (most applicable to VS 19 users experiencing bad perf due to source generators)
This is just as applicable for VS 22, because there may be by now various third-party libraries shipping their own V1 source generators that would slow VS down. So there should be a way to disable source generators at a project / IDE level by either API version, assembly, or both.
eerhardt
commented
3 years ago Identify multi-targeting strategy for shipping both v1 and v2 implementations for use in various IDE & SDK scenarios
The multi-targeting strategy is only necessary for the NuGet package, correct? For the source generators contained in the ref-pack, we should just always use v2, as this is net6.0, which only works with Roslyn v4.0.
PathogenDavid
commented
3 years ago Identify multi-targeting strategy for shipping both v1 and v2 implementations for use in various IDE & SDK scenarios
For NuGet packages I believe https://github.com/dotnet/roslyn/issues/54108 is intended to provide a canonical way to do this.
sharwell
commented
3 years ago For NuGet packages I believe dotnet/roslyn#54108 is intended to provide a canonical way to do this.
@PathogenDavid This approach will only work with environments that understand the new packaging conventions, which means it probably won't work with Roslyn 3.x / VS 2019.
fitdev
commented
3 years ago Just wanted to say that the issue exists in latest VS 2022 Preview 3.1 and DotNet 6 Preview 7. VS is frequently blocked even when typing a mere xml doc comment - something completely unrelated to source generators, let alone Json Source Generator!
Here's the sample stack trace during the "mini-hang" of one of VS's threads:
0, ntoskrnl.exe!KeWaitForSingleObject+0x30c1
1, ntoskrnl.exe!KeWaitForSingleObject+0x1521
2, ntoskrnl.exe!KeWaitForSingleObject+0xadb
3, ntoskrnl.exe!KeWaitForSingleObject+0x1ff
4, ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x9fa
5, ntoskrnl.exe!KeWaitForSingleObject+0x31cb
6, ntoskrnl.exe!KiCheckForKernelApcDelivery+0x27
7, ntoskrnl.exe!KeLeaveGuardedRegion+0x2c
8, FLTMGR.SYS!FltDecodeParameters+0x17be
9, FLTMGR.SYS!FltDecodeParameters+0x14dc
10, FLTMGR.SYS!FltDecodeParameters+0x5f4
11, FLTMGR.SYS!FltDecodeParameters+0x3ee
12, ntoskrnl.exe!IofCallDriver+0x59
13, ntoskrnl.exe!SePrivilegeCheck+0x994
14, ntoskrnl.exe!NtWaitForSingleObject+0x200
15, ntoskrnl.exe!ObfDereferenceObjectWithTag+0xc6
16, ntoskrnl.exe!SeLockSubjectContext+0x2b9
17, ntoskrnl.exe!NtClose+0xcd
18, ntoskrnl.exe!setjmpex+0x6f03
19, ntdll.dll!NtClose+0x14
20, KernelBase.dll!CloseHandle+0x62
21, clr.dll!StrongNameTokenFromPublicKey+0xdd77
22, clr.dll!StrongNameTokenFromPublicKey+0xdad0
23, clr.dll!StrongNameTokenFromPublicKey+0xd90f
24, clr.dll!LogHelp_NoGuiOnAssert+0x6fe38
25, clr.dll!CorExeMain+0x3e0ad
26, clr.dll!NGenCreateNGenWorker+0x2685
27, clr.dll!TranslateSecurityAttributes+0x1c1435
28, System.Reflection.AssemblyName.GetAssemblyName(System.String) + 0x6a <-- mscorlib.ni.dll+0x5a806a
29, System.Linq.Enumerable.ToDictionary[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.Collections.Generic.IEnumerable`1<System.__Canon>, System.Func`2<System.__Canon,System.__Canon>, System.Func`2<System.__Canon,System.__Canon>, System.Collections.Generic.IEqualityComparer`1<System.__Canon>) + 0xfb <-- System.Core.ni.dll+0x34282b
30, System.Text.Json.Reflection.MetadataLoadContextInternal..ctor(Microsoft.CodeAnalysis.Compilation) + 0x197 <-- 0x7ffddd493117
31, System.Text.Json.SourceGeneration.JsonSourceGenerator+Parser..ctor(Microsoft.CodeAnalysis.GeneratorExecutionContext ByRef) + 0x147 <-- 0x7ffddd491617
32, System.Text.Json.SourceGeneration.JsonSourceGenerator.Execute(Microsoft.CodeAnalysis.GeneratorExecutionContext) + 0x60 <-- 0x7ffddd490cb0
33, Microsoft.CodeAnalysis.SourceGeneratorAdaptor.<Initialize>b__4_5(Microsoft.CodeAnalysis.SourceProductionContext, GeneratorContextBuilder) + 0xf2 <-- 0x7ffddd48fea2
34, Microsoft.CodeAnalysis.UserFunctionExtensions+<>c__DisplayClass3_0`2[[Microsoft.CodeAnalysis.SourceProductionContext, Microsoft.CodeAnalysis],[System.__Canon, mscorlib]].<WrapUserAction>b__0(Microsoft.CodeAnalysis.SourceProductionContext, System.__Canon) + 0x23 <-- 0x7ffddd48fad3
35, Microsoft.CodeAnalysis.SourceOutputNode`1[[System.__Canon, mscorlib]].UpdateStateTable(Builder, Microsoft.CodeAnalysis.NodeStateTable`1<System.ValueTuple`2<System.Collections.Generic.IEnumerable`1<Microsoft.CodeAnalysis.GeneratedSourceText>,System.Collections.Generic.IEnumerable`1<Microsoft.CodeAnalysis.Diagnostic>>>, System.Threading.CancellationToken) + 0x205 <-- 0x7ffddd4516a5
36, Microsoft.CodeAnalysis.DriverStateTable+Builder.GetLatestStateTableForNode[[System.ValueTuple`2[[System.__Canon, mscorlib],[System.__Canon, mscorlib]], mscorlib]](Microsoft.CodeAnalysis.IIncrementalGeneratorNode`1<System.ValueTuple`2<System.__Canon,System.__Canon>>) + 0x110 <-- 0x7ffddd44e220
37, Microsoft.CodeAnalysis.SourceOutputNode`1[[System.__Canon, mscorlib]].AppendOutputs(Microsoft.CodeAnalysis.IncrementalExecutionContext, System.Threading.CancellationToken) + 0x4d <-- 0x7ffddd44cfdd
38, Microsoft.CodeAnalysis.GeneratorDriver.UpdateOutputs(System.Collections.Immutable.ImmutableArray`1<Microsoft.CodeAnalysis.IIncrementalGeneratorOutputNode>, Microsoft.CodeAnalysis.IncrementalGeneratorOutputKind, System.Threading.CancellationToken, Builder) + 0x197 <-- 0x7ffddd44bf57
39, Microsoft.CodeAnalysis.GeneratorDriver.RunGeneratorsCore(Microsoft.CodeAnalysis.Compilation, Microsoft.CodeAnalysis.DiagnosticBag, System.Threading.CancellationToken) + 0xa11 <-- 0x7ffddd446da1
40, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<FinalizeCompilationAsync>d__30.MoveNext() + 0xce8 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fe958
41, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].Start[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<FinalizeCompilationAsync>d__30, Microsoft.CodeAnalysis.Workspaces]](<FinalizeCompilationAsync>d__30 ByRef) + 0x87 <-- 0x7ffddbbef3c7
42, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.FinalizeCompilationAsync(Microsoft.CodeAnalysis.SolutionState, Microsoft.CodeAnalysis.Compilation, System.Nullable`1<Microsoft.CodeAnalysis.TextDocumentStates`1<Microsoft.CodeAnalysis.SourceGeneratedDocumentState>>, Microsoft.CodeAnalysis.TextDocumentStates`1<Microsoft.CodeAnalysis.SourceGeneratedDocumentState>, Microsoft.CodeAnalysis.Compilation, Microsoft.CodeAnalysis.GeneratorDriver, System.Threading.CancellationToken) + 0xbd <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fc31d
43, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.BuildCompilationInfoAsync(Microsoft.CodeAnalysis.SolutionState, System.Threading.CancellationToken) + 0x37e <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x1026189
44, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetOrBuildCompilationInfoAsync>d__22.MoveNext() + 0x4a3 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fcc53
45, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].Start[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetOrBuildCompilationInfoAsync>d__22, Microsoft.CodeAnalysis.Workspaces]](<GetOrBuildCompilationInfoAsync>d__22 ByRef) + 0x87 <-- 0x7ffddbbeee87
46, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.GetOrBuildCompilationInfoAsync(Microsoft.CodeAnalysis.SolutionState, Boolean, System.Threading.CancellationToken) + 0x62 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x821f42
47, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetCompilationSlowAsync>d__20.MoveNext() + 0x61 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fc631
48, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib]].Start[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetCompilationSlowAsync>d__20, Microsoft.CodeAnalysis.Workspaces]](<GetCompilationSlowAsync>d__20 ByRef) + 0x81 <-- 0x7ffddbbeecf1
49, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.GetCompilationSlowAsync(Microsoft.CodeAnalysis.SolutionState, System.Threading.CancellationToken) + 0x5e <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x821ebe
50, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetMetadataReferenceAsync>d__31.MoveNext() + 0x120 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x903c00
51, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib]].Start[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetMetadataReferenceAsync>d__31, Microsoft.CodeAnalysis.Workspaces]](<GetMetadataReferenceAsync>d__31 ByRef) + 0x81 <-- 0x7ffddd431c11
52, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.GetMetadataReferenceAsync(Microsoft.CodeAnalysis.SolutionState, Microsoft.CodeAnalysis.ProjectState, Microsoft.CodeAnalysis.ProjectReference, System.Threading.CancellationToken) + 0x73 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x822483
53, Microsoft.CodeAnalysis.SolutionState.GetMetadataReferenceAsync(Microsoft.CodeAnalysis.ProjectReference, Microsoft.CodeAnalysis.ProjectState, System.Threading.CancellationToken) + 0x4f <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x7df79f
54, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<FinalizeCompilationAsync>d__30.MoveNext() + 0x53e <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fe1ae
55, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].Start[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<FinalizeCompilationAsync>d__30, Microsoft.CodeAnalysis.Workspaces]](<FinalizeCompilationAsync>d__30 ByRef) + 0x87 <-- 0x7ffddbbef3c7
56, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.FinalizeCompilationAsync(Microsoft.CodeAnalysis.SolutionState, Microsoft.CodeAnalysis.Compilation, System.Nullable`1<Microsoft.CodeAnalysis.TextDocumentStates`1<Microsoft.CodeAnalysis.SourceGeneratedDocumentState>>, Microsoft.CodeAnalysis.TextDocumentStates`1<Microsoft.CodeAnalysis.SourceGeneratedDocumentState>, Microsoft.CodeAnalysis.Compilation, Microsoft.CodeAnalysis.GeneratorDriver, System.Threading.CancellationToken) + 0xbd <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fc31d
57, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.BuildCompilationInfoAsync(Microsoft.CodeAnalysis.SolutionState, System.Threading.CancellationToken) + 0x37e <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x1026189
58, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetOrBuildCompilationInfoAsync>d__22.MoveNext() + 0x4a3 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fcc53
59, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].Start[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetOrBuildCompilationInfoAsync>d__22, Microsoft.CodeAnalysis.Workspaces]](<GetOrBuildCompilationInfoAsync>d__22 ByRef) + 0x87 <-- 0x7ffddbbeee87
60, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.GetOrBuildCompilationInfoAsync(Microsoft.CodeAnalysis.SolutionState, Boolean, System.Threading.CancellationToken) + 0x62 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x821f42
61, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetCompilationSlowAsync>d__20.MoveNext() + 0x61 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fc631
62, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib]].Start[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetCompilationSlowAsync>d__20, Microsoft.CodeAnalysis.Workspaces]](<GetCompilationSlowAsync>d__20 ByRef) + 0x81 <-- 0x7ffddbbeecf1
63, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.GetCompilationSlowAsync(Microsoft.CodeAnalysis.SolutionState, System.Threading.CancellationToken) + 0x5e <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x821ebe
64, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetMetadataReferenceAsync>d__31.MoveNext() + 0x120 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x903c00
65, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib]].Start[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetMetadataReferenceAsync>d__31, Microsoft.CodeAnalysis.Workspaces]](<GetMetadataReferenceAsync>d__31 ByRef) + 0x81 <-- 0x7ffddd431c11
66, Microsoft.CodeAnalysis.SolutionState+CompilationTracker.GetMetadataReferenceAsync(Microsoft.CodeAnalysis.SolutionState, Microsoft.CodeAnalysis.ProjectState, Microsoft.CodeAnalysis.ProjectReference, System.Threading.CancellationToken) + 0x73 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x822483
67, Microsoft.CodeAnalysis.SolutionState.GetMetadataReferenceAsync(Microsoft.CodeAnalysis.ProjectReference, Microsoft.CodeAnalysis.ProjectState, System.Threading.CancellationToken) + 0x4f <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x7df79f
68, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<FinalizeCompilationAsync>d__30.MoveNext() + 0x53e <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fe1ae
69, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
70, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
71, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
72, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
73, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
74, System.Threading.Tasks.Task`1[[System.__Canon, mscorlib]].TrySetResult(System.__Canon) + 0x68 <-- mscorlib.ni.dll+0x566a88
75, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib]].SetResult(System.__Canon) + 0xa3 <-- mscorlib.ni.dll+0x5fc333
76, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetMetadataReferenceAsync>d__31.MoveNext() + 0x374 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x903e54
77, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
78, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
79, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
80, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
81, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
82, System.Threading.Tasks.Task`1[[System.__Canon, mscorlib]].TrySetResult(System.__Canon) + 0x68 <-- mscorlib.ni.dll+0x566a88
83, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib]].SetResult(System.__Canon) + 0xa3 <-- mscorlib.ni.dll+0x5fc333
84, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetCompilationSlowAsync>d__20.MoveNext() + 0x17b <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fc74b
85, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
86, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
87, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
88, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
89, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
90, System.Threading.Tasks.Task`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].TrySetResult(CompilationInfo) + 0x7d <-- 0x7ffddbc503dd
91, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].SetResult(CompilationInfo) + 0xef <-- 0x7ffddbbfccff
92, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetOrBuildCompilationInfoAsync>d__22.MoveNext() + 0x7b2 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fcf62
93, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
94, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
95, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
96, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
97, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
98, System.Threading.Tasks.Task`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].TrySetResult(CompilationInfo) + 0x7d <-- 0x7ffddbc503dd
99, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].SetResult(CompilationInfo) + 0xef <-- 0x7ffddbbfccff
100, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<FinalizeCompilationAsync>d__30.MoveNext() + 0x162d <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8ff29d
101, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
102, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
103, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
104, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
105, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
106, System.Threading.Tasks.Task`1[[System.__Canon, mscorlib]].TrySetResult(System.__Canon) + 0x68 <-- mscorlib.ni.dll+0x566a88
107, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib]].SetResult(System.__Canon) + 0xa3 <-- mscorlib.ni.dll+0x5fc333
108, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetMetadataReferenceAsync>d__31.MoveNext() + 0x374 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x903e54
109, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
110, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
111, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
112, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
113, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
114, System.Threading.Tasks.Task`1[[System.__Canon, mscorlib]].TrySetResult(System.__Canon) + 0x68 <-- mscorlib.ni.dll+0x566a88
115, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib]].SetResult(System.__Canon) + 0xa3 <-- mscorlib.ni.dll+0x5fc333
116, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetCompilationSlowAsync>d__20.MoveNext() + 0x17b <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fc74b
117, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
118, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
119, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
120, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
121, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
122, System.Threading.Tasks.Task`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].TrySetResult(CompilationInfo) + 0x7d <-- 0x7ffddbc503dd
123, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[Microsoft.CodeAnalysis.SolutionState+CompilationTracker+CompilationInfo, Microsoft.CodeAnalysis.Workspaces]].SetResult(CompilationInfo) + 0xef <-- 0x7ffddbbfccff
124, Microsoft.CodeAnalysis.SolutionState+CompilationTracker+<GetOrBuildCompilationInfoAsync>d__22.MoveNext() + 0x7b2 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x8fcf62
125, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
126, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
127, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
128, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
129, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
130, System.Threading.Tasks.Task`1[[Roslyn.Utilities.SemaphoreSlimExtensions+SemaphoreDisposer, Microsoft.CodeAnalysis.Workspaces]].TrySetResult(SemaphoreDisposer) + 0x72 <-- 0x7ffddbbd6922
131, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[Roslyn.Utilities.SemaphoreSlimExtensions+SemaphoreDisposer, Microsoft.CodeAnalysis.Workspaces]].SetResult(SemaphoreDisposer) + 0xa3 <-- 0x7ffddbbd6843
132, Roslyn.Utilities.SemaphoreSlimExtensions+<DisposableWaitAsync>d__1.MoveNext() + 0x177 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x80e237
133, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
134, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
135, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
136, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
137, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
138, System.Threading.Tasks.Task`1[[System.Boolean, mscorlib]].TrySetResult(Boolean) + 0x5e <-- mscorlib.ni.dll+0x5aaf0e
139, System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.Boolean, mscorlib]].SetResult(Boolean) + 0x9f <-- mscorlib.ni.dll+0x5ab01f
140, System.Threading.SemaphoreSlim+<WaitUntilCountOrTimeoutAsync>d__31.MoveNext() + 0x442 <-- mscorlib.ni.dll+0x1010632
141, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
142, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
143, System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() + 0x6f <-- mscorlib.ni.dll+0x5fd00f
144, System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) + 0x63 <-- mscorlib.ni.dll+0x602523
145, System.Threading.Tasks.Task.FinishContinuations() + 0x400 <-- mscorlib.ni.dll+0x566f40
146, System.Threading.Tasks.Task`1[[System.__Canon, mscorlib]].TrySetResult(System.__Canon) + 0x68 <-- mscorlib.ni.dll+0x566a88
147, System.Threading.Tasks.TaskFactory+CompleteOnInvokePromise.Invoke(System.Threading.Tasks.Task) + 0xab <-- mscorlib.ni.dll+0x1014c1b
148, System.Threading.Tasks.Task.FinishContinuations() + 0x447 <-- mscorlib.ni.dll+0x566f87
149, System.Threading.Tasks.Task`1[[System.Boolean, mscorlib]].TrySetResult(Boolean) + 0x5e <-- mscorlib.ni.dll+0x5aaf0e
150, System.Threading.SemaphoreSlim+TaskNode.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x10 <-- mscorlib.ni.dll+0x100f0a0
151, System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x156 <-- mscorlib.ni.dll+0x558e46
152, clr.dll!CoUninitializeEE+0x1b93
153, clr.dll!CoUninitializeEE+0x1a98
154, clr.dll!CoUninitializeEE+0x2358
155, clr.dll!CoUninitializeEE+0x737a
156, clr.dll!CoUninitializeEE+0x2f50
157, clr.dll!CoUninitializeEE+0x2ec3
158, clr.dll!CoUninitializeEE+0x2e02
159, clr.dll!CoUninitializeEE+0x2fe7
160, clr.dll!CoUninitializeEE+0x72c7
161, clr.dll!CoUninitializeEE+0x2b17
162, clr.dll!CoUninitializeEE+0x29ef
163, clr.dll!CoUninitializeEE+0x6835
164, kernel32.dll!BaseThreadInitThunk+0x14
165, ntdll.dll!RtlUserThreadStart+0x21... something completely unrelated to source generators ...
Source generators using the V1 API (as JsonSourceGenerators does) do not distinguish one location in a source file from any other. All locations, including within comments, are equivalent and treated as relevant for them.
fitdev
commented
3 years ago Oh I see. Thank you for pointing this out. Well, I really hope for RTM you move all source generators to V2 and provide clear mechanism to disable all source generators (that may be coming from 3rd party nugets). Because in a solution with ~60 projects and a few thousand files this leads to very serious slowdowns, which is made even worse by the fact that this CPU time is basically wasted since the actual coding does not have anything to do with source generators, and thus ideally none of them should run in the first place.
mayur-ekbote
commented
3 years ago Facing the same issue after moving to .net 6. I do not use any source generators. CPU usage routinely hits 100% after a few keystrokes.
eerhardt
commented
3 years ago With #58271 and #58278, the sluggish performance has been addressed in VS 2022. You should see these changes in 6.0-rc1.
Version Used: Latest Official DotNet 6 Preview 6 Latest VS previews: VS 2019 16.11 Preview 3 and VS 2022 Preview 2 C#: 10 (
<LangVersion>preview</LangVersion>, includingglobal usings in a few places)Steps to Reproduce: VS typing performance quickly degrades (hangs, up to several seconds pauses between characters typing, etc.) after working with several
csfiles for like 20 minutes or more in the context of a medium-sized DotNet 6 Preview 6 solution with maybe 70 projects, each with ~ 10 to 500 files.It started with DotNet6 Preview 5, which made VS 2019 run out of memory pretty quickly (GC was happening so often, that basically after about 1 hour of typing in a few files, it became unusable due to constant GC pauses, and VS's Private Bytes being near 2.5GB).
VS 2022 in this regard was very timely, but it did not improve things much. The performance is better compared with 2019, because GCs happen much more rarely and not as aggressively, but there are still very frequent hangs and slowdowns that happen more and more often as time goes on. This is actually happening while doing very mundane things - for example just editing a few 500-line files in an hour, perhaps renaming a few variables, etc. Nothing super-heavy like editing 100s of files, or refactoring whole namespaces, etc.
So I investigated this and came to conclude that
Microsoft.CodeAnalysiswas always the culprit.Evidence: Stack Traces
First, in both VS 2019 and 2022, when I was examining stack traces of VS's threads during slowdowns, I saw references to
Microsoft.CodeAnalysis.SourceGener*types all the time:Evidence: Memory and Managed Heap Snapshots
When I attached another instance of VS to "debug" the problematic instance, and took managed heap snapshots, I noticed that the lion's share of allocated bytes was once again for types in
Microsoft.CodeAnalysis. Some types had over a million instances! This was not the case prior to DotNet 6 Preview 5 and prior to Preview 5 VS 2019 was not running out of memory at all on the same solution.Issue with Source Generators
Now, according to every stack trace that I took of VS's threads when it was misbehaving, it always involved
Microsoft.CodeAnalysis.SourceGeneratedDocumentStateandSystem.Text.Json.SourceGenerationtypes.Also note that my solution does NOT use any source generators. And VS's option
Text Editor > VB/C# > Advanced > Enable all features in opened files from source generators (experimental)is tuned OFF.I presume it might have something to do with Source Generator support being automatically included for
System.Text.Jsonstarting with Preview 5 (a was noted in your blog post), and so obviously it is applicable to me as I am now on Preview 6.Expected Behavior: VS 2019 does not run out of memory. VS 2019 and VS 2022 do not slow down and become sluggish after typing a few characters / words.
Actual Behavior: Both VS 2019 and 2022 are slowed down, with VS 2019 being slowed down to the point of being completely unusable (due to memory pressure and GC), while VS 2022 is usable but typing experience deteriorates very quickly and becomes often literally one or a few characters per second (i.e. >500ms pause after each character on average).
It does not seem to correlate with what file I edit (large or small), what text I edit (comment, type name, variable name, code), and which project the file comes from (one on which other projects in the solution depend, or the one on which no other projects depend).