-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Redo how and when we report source generator telemetry #79951
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
Redo how and when we report source generator telemetry #79951
Conversation
2400c48 to
1d3fce2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I'm thinking of the volume of telemetry data this would bring in. Maybe there's precedent to some of that already though? However it would be nice if we had something tracking this:
There is work happening that would allow us to have an asynchronous handler there again which we can look at moving back to later.
|
will review tomorrow :) |
We're only sending telemetry every five minutes, and only if there is something to report. I intentionally did a bit of extra work so we'll go idle if the user has VS running in a way they forgot about, we're not going to keep pinging their CPU just to do nothing. I'd generally expect that in an active VS session we're going to be firing up a lot of more telemetry events in response to user events.... |
...io/Core/Def/Workspace/VisualStudioSourceGeneratorTelemetryReporterWorkspaceServiceFactory.cs
Outdated
Show resolved
Hide resolved
...io/Core/Def/Workspace/VisualStudioSourceGeneratorTelemetryReporterWorkspaceServiceFactory.cs
Outdated
Show resolved
Hide resolved
...io/Core/Def/Workspace/VisualStudioSourceGeneratorTelemetryReporterWorkspaceServiceFactory.cs
Outdated
Show resolved
Hide resolved
src/Workspaces/Core/Portable/SourceGeneration/IRemoteSourceGenerationService.cs
Show resolved
Hide resolved
.../Core/Portable/SourceGeneratorTelemetry/SourceGeneratorTelemetryCollectorWorkspaceService.cs
Outdated
Show resolved
Hide resolved
.../Core/Portable/SourceGeneratorTelemetry/SourceGeneratorTelemetryCollectorWorkspaceService.cs
Show resolved
Hide resolved
...viceHub/Services/SourceGeneration/RemoteWorkspaceSourceGeneratorCollectorTelemetryService.cs
Outdated
Show resolved
Hide resolved
...viceHub/Services/SourceGeneration/RemoteWorkspaceSourceGeneratorCollectorTelemetryService.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
signing off with some minor feedback. i leave it to you if you want to take it.
Previously, we were triggering a report of source generator telemetry when the user closed the solution. The intent of this was to be able to do it prior to "context" that the telemetry service has set is cleared; this means we could understand the performance for one solution versus another. This approach however was broken once we moved the computation of source generators OOP; this meant we'd report the 'in-process' results, which are almost always empty. This switches to reporting the results for all out-of-process and in- process runs. Unfortunately, the trick of us doing it during solution close isn't possible without blocking the UI thread synchronously on OOP which we don't want to do, so for now we'll just report telemetry every few minutes as long as there's new telemetry to report. There is work happening that would allow us to have an asynchronous handler there again which we can look at moving back to later.
1d3fce2 to
d40cd16
Compare
|
@CyrusNajmabadi Feedback was good, thank you! |
46 PRs before and 36 after ```diff + * [Cache diagnostic analyzer computation](dotnet/roslyn#80045) + * [Remove parameter always passed the same value](dotnet/roslyn#80042) * [Update doc for IMethodSymbol.IsExtensionMethod](dotnet/roslyn#80016) * [Don't cache known-broken compositions](dotnet/roslyn#80021) * [Cleanup methods in DiagAnalyzerService](dotnet/roslyn#80013) * [Simplify processing of errors reported by the build](dotnet/roslyn#79964) * [Additional cleanup of the DiagnosticAnalyzerServier](dotnet/roslyn#80005) * [Fix Code Lens around source generated files](dotnet/roslyn#79992) * [Remove superflous DiagService api that can be achieved with existing apis](dotnet/roslyn#80007) * [Generate `init` accessor for required properties inside `readonly struct`s](dotnet/roslyn#80004) * [Remove existing low level diag oop code now that it's all handled at higher levels.](dotnet/roslyn#79994) * [Allow large InlineHint ArrayBuilder pooling](dotnet/roslyn#79857) * [Reduce allocations obtaining classified spans in ClassifierHelper](dotnet/roslyn#79856) * [Compute span diagnostics in oop](dotnet/roslyn#79991) * [Allow Razor cohosting to work with non-Razor SDK projects](dotnet/roslyn#79953) * [Move computation of deprioritized analyzers to oop](dotnet/roslyn#79989) * [EnC: Fix symbol mapping of delegates with indexed name](dotnet/roslyn#79837) * [Emit telemetry 'durations' with known radix point '.'](dotnet/roslyn#79988) * [Move logic up into DiagService](dotnet/roslyn#79985) * [Move the StateManager type up to the DiagnosticService from the DiagnosticIncrementalANalyzer](dotnet/roslyn#79984) * [Immediately remote diagnostics call to OOP](dotnet/roslyn#79983) * [Build Microsoft.CodeAnalysis.SemanticSearch.Extension ref assembly for use in semantic search queries](dotnet/roslyn#79972) * [Only cache compilation if we have the same set of analyzers](dotnet/roslyn#79978) * [Delete unused property](dotnet/roslyn#79963) * [Update 'use expr body' to be a purely syntactic analyzer](dotnet/roslyn#79979) * [Mark 'Use expr body' as a syntax-only fixer](dotnet/roslyn#79971) * [♻️ MSBuildWorkspaceDirectory - Fallback to AppContext.BaseDirectory when Assembly Location is empty](dotnet/roslyn#79934) * [Merge runtime async support into main](dotnet/roslyn#79833) * [Implement "Simplify property accessor" feature](dotnet/roslyn#79754) - * Merge main to runtime async branch (PR: [#79961](dotnet/roslyn#79961)) * [Redo how and when we report source generator telemetry](dotnet/roslyn#79951) * [Allow MEF components to supply assembly path resolvers](dotnet/roslyn#79218) * [Allow Razor to hook up the source generator in misc files](dotnet/roslyn#79891) * [Block ENC for extension blocks](dotnet/roslyn#79883) * [Upgrade servicehub.client to fix test source discovery](dotnet/roslyn#79899) * [Update package restore error message.](dotnet/roslyn#79876) - * Merge main (PR: [#79834](dotnet/roslyn#79834)) - * Merge main (PR: [#79830](dotnet/roslyn#79830)) * [Baseline struct lifting tests](dotnet/roslyn#79505) - * Merge main to runtime async branch (PR: [#79582](dotnet/roslyn#79582)) - * Merge main (PR: [#79424](dotnet/roslyn#79424)) - * Merge main (PR: [#78994](dotnet/roslyn#78994)) - * Merge main to runtime async branch (PR: [#78740](dotnet/roslyn#78740)) - * Merge main to runtime async branch (PR: [#78517](dotnet/roslyn#78517)) - * Merge main to runtime async branch (PR: [#78114](dotnet/roslyn#78114)) - * Merge main to runtime async branch (PR: [#77700](dotnet/roslyn#77700)) - * Merge main to runtime async branch (PR: [#77533](dotnet/roslyn#77533)) - * Merge main to runtime async branch (PR: [#77265](dotnet/roslyn#77265)) ```
Previously, we were triggering a report of source generator telemetry when the user closed the solution. The intent of this was to be able to do it prior to "context" that the telemetry service has set is cleared; this means we could understand the performance for one solution versus another.
This approach however was broken once we moved the computation of source generators OOP; this meant we'd report the 'in-process' results, which are almost always empty.
This switches to reporting the results for all out-of-process and in- process runs. Unfortunately, the trick of us doing it during solution close isn't possible without blocking the UI thread synchronously on OOP which we don't want to do, so for now we'll just report telemetry every few minutes as long as there's new telemetry to report. There is work happening that would allow us to have an asynchronous handler there again which we can look at moving back to later.