Repository navigation
NativeRuntimeEventSource is too slow initialized #60963
Description
We have moved PowerShell 7.2 RC to latest pre-RTM .Net 6.0 build and I see 20% perf win in startup scenario vs PowerShell 7.1 based on .Net 5.0. Thanks .Net team for great work!
Nevertheless I still see in PerfView that System.Diagnostics.Tracing.NativeRuntimeEventSource::.cctor() is noticeable slow - in my test it is 12% in PowerShell startup scenario. (Trace file PerfViewData-7.2-Startup-Exit.speedscope.json.zip )
It seems a root of the issue System.Attribute::GetCustomAttributes(System.Reflection.MemberInfo, System.Type, System.Boolean) is slow.
There is related issue #44713. Too bad it wasn't fixed in the #45121. :-(
Activity
stephentoub commentedon Oct 28, 2021
There's a catch-22 here: the costs you're seeing mostly only show up as part of running a trace, as it's the act of enabling ETW that's causing the EventSource to generate and output its manifest, which in turn is what's triggering it to use reflection to walk itself. So these costs generally don't show up in real usage and only appear because you're looking at it.
The answer here isn't to try to make getting attributes faster, it's to avoid needing to do it at all. #49659 tracks that.
Also #43390.
iSazonov commentedon Oct 28, 2021
PowerShell uses System.Diagnostics.Tracing at startup too and I hope it can benefit if GetCustomAttributes will be faster.
I doubt that it is possible to completely avoid dependence on custom attributes in PowerShell but I hope we will benefit directly and indirectly from source generators in the area too.
stephentoub commentedon Oct 28, 2021
Do you mean it has its own EventSource? That would be covered by an EventSource source generator as well.
iSazonov commentedon Oct 28, 2021
Yes, 3 at least. And yes, I hope PowerShell could benefit from source generators.
stephentoub commentedon Oct 28, 2021
Right. That's covered by the other issues. I'll close this then.