Typing in Razor files breaks C# incrementality resulting in high CPU & memory usage

[NTaylorMullen]

Overview:
Razor IDynamicFileInfoProvider output is fed into SourceGenerators which breaks C# incrementality and significantly impacts performance.

Version Used: All

Steps to Reproduce:

1. Create a Blazor server application
2. Open Index.razor

Expected Behavior:
Generated output from Index.razor is not fed into Json SourceGenerators

Actual Behavior:
Generated output from Index.razor is fed into Json SourceGenerators

Additional Notes:
@sharwell and I were investigating customer reports of high CPU utilization in Razor scenarios. Turns out Razor files (they emit larger C# files) are always fed into the Json, Logging & any other source generator. This in turn results in a lot of extra CPU churn for Razor projects. After digging into some traces we can see HEAVY allocations in the Roslyn service hub process from the realization of red trees from the Razor files:

One implementation note we should think of is that we also have a counter issue where the Regex generators in .NET 7 do not run on Razor output resulting in the new Regex .NET 7 capabilities missing.

/cc @jasonmalinowski

[NTaylorMullen]

Related VS Feedback issues: https://developercommunity.visualstudio.com/t/Editing-Blazor-files-consumes-all-CPU-fo/1676170

[jcouv]

Assigning to @chsienki to triage.

[NTaylorMullen]

More:

• https://developercommunity.visualstudio.com/t/VS-2022---Blazor-Development-Experience/1684379
• https://developercommunity.visualstudio.com/t/Razor-editor-very-slow-impossible-to-wo/1703121

[jcouv]

From discussion with @chsienki, the issue is that IDynamicFiles generated by Razor are visible to other source generators.
Some options:

1. migrating legacy to Razor to source generators (unlikely in short-term)
2. add some kind of filtering

[jasonmalinowski]

This made it in for 17.2 Preview 4.

[Mike-E-angelo]

Thank you all very much for all your diligent and amazing work out there. It is greatly appreciated and respected. 🙏