Repository navigation
85% of pre-Main startup with VS open is Runtime/Native EventSource constructors #49592
Description
If Visual Studio is open on a .NET project; it registers for verbose .NET events #45059 (comment), causing all .NET programs system-wide to take additional time to start-up due to the additional Windows Etw time in the EventSource constructors.
For this minimal program it takes 282ms to start running Main and 300ms to get to Console.ReadKey (current 6.0 main branch)
using System;
Console.WriteLine("Press a key to exit");
Console.ReadKey();86% (246ms) of that is the RuntimeEventSource constructor.
Data
Analysis
The majority of the time is RuntimeEventSource activating NativeEventSource and in there the majority is creating Manifests, Descriptors and Pipe Events.
All three are fixed data; however generated using reflection, StringBuilder and Encoding.UTF8 during startup.
The manifests and pipe events are byte arrays so could be created as ReadOnlySpan<byte> data sections by source generators.
The Event Descriptors also could be generated as regular new statements with source generators rather than using runtime reflection.
Activity
stephentoub commentedon Mar 14, 2021
@benaadams, I realize it's a catch-22 from a measurement perspective, but the times you've cited are only when profiling, right? On my machine, a console app .exe created from
dotnet new consoletakes ~90ms to run.[-]240ms (85%) of pre-Main startup is Runtime/Native EventSource constructors[/-][+]85% of pre-Main startup is Runtime/Native EventSource constructors[/+]benaadams commentedon Mar 14, 2021
85% of that is probably still the EventSource constructors, so ~76ms? 🤔
stephentoub commentedon Mar 14, 2021
I suspect not. I think the EventSource times are significantly increased with the profiler attached because it's forcing them to do work they wouldn't otherwise do if the events weren't enabled.
benaadams commentedon Mar 14, 2021
Does also depend if
DoCommandis run; which does the manifest initialization, however... we've also established just having VS open on a .NET project will trigger that #45059 (comment), don't need to profile or have a debugger attached; so fits with "developer's inner loop startup" #44598?benaadams commentedon Mar 14, 2021
Either VS shouldn't register a system-wide event listener from just having a .NET project open (it adds two more when debugging #45059 (comment) so isn't that); or it should be much faster since it effects the activation of every .NET (5?) app regardless of whether its the one open in VS.
benaadams commentedon Mar 14, 2021
Using sampling, which is less invasive and definitely doesn't trigger
DoCommandVS not open
VS open in background on a .NET project
As
dotnet build -c Releasefor an exe project with 2 .csproj libs will spawn 4 .NET exes it starts to add up?benaadams commentedon Mar 14, 2021
Running
dotnet build -c Releaseinruntime\src\libraries\System.Text.Jsoncreates 66dotnetprocesses; if its adding 167ms to each one (from above); that's 11 secs of extra time?AraHaan commentedon Mar 14, 2021
why so many dotnet.exe's 🤔
benaadams commentedon Mar 14, 2021
dependencies in the project tree its building/checking to build
[-]85% of pre-Main startup is Runtime/Native EventSource constructors[/-][+]85% of pre-Main startup with VS open is Runtime/Native EventSource constructors[/+]brianrob commentedon Mar 14, 2021
@benaadams, question for you. Did you happen to have the VS performance tools open when you saw this, or was this just the result of having a VS window open?
benaadams commentedon Mar 14, 2021
Just VS open; must also have a .NET project loaded however, doesn't register if its just open
benaadams commentedon Mar 14, 2021
More specifically it looks to be "Microsoft-VisualStudio-Telemetry-PerfWatson2"
3rd provider
e13c0d23-ccbc-4e12-931b-d9cc2eee27e4benaadams commentedon Mar 14, 2021
Does look like I could opt out of the "Visual Studio Customer Experience Improvement Program" to disable it; but I'd assume its preferred to stay in... 😉
brianrob commentedon Mar 15, 2021
Totally. Reaching out to the VS folks on this, and will report back.
stephentoub commentedon Mar 16, 2021
We're working with the VS folks to reduce the scope of the tracing from PerfWatson to just the devenv process.
@sywhang is also working on a source generator for EventSource, though the initial scope of that will just be for the ones in System.Private.CoreLib. That's covered by #49659, and builds on the work you did, @benaadams.
Is there anything further highlighted in this issue to be addressed?
Thanks!
benaadams commentedon Mar 16, 2021
No, those should address it
tommcdon commentedon Mar 19, 2021
Closing this issue since the outstanding runtime work is tracked #49659, and the VS PerfWatson investigation is being tracked internally. Please feel free to let us know if we should re-activate.