Regression in New BlazorServer Template Build Time

Describe the bug

There is a ~850ms regression in the BlazorServer template build time in the perf lab.

To Reproduce

1. Download the latest SDK.
2. dotnet new blazorserver
3. dotnet build

On my local machine, this shows up as a warm regression (not the first run) of 197ms. Here are the longest 6 targets of each run. I have narrowed it down to at the CoreCompile target - possibly some affect from ResolveAssemblyReferences.

Baseline:

Event Name | Time MSec | Process Name | DURATION__MSEC | targetName
Microsoft-Build/Target/Stop | 7,469.455 | dotnet (21624) | 290.792 | CoreCompile
Microsoft-Build/Target/Stop | 7,021.423 | dotnet (21624) | 196.984 | ResolveAssemblyReferences
Microsoft-Build/Target/Stop | 7,798.614 | dotnet (21624) | 193.787 | _GenerateScopedCssFiles
Microsoft-Build/Target/Stop | 6,535.790 | dotnet (21624) | 190.571 | Restore
Microsoft-Build/Target/Stop | 7,584.268 | dotnet (21624) | 114.501 | _CreateAppHost
Microsoft-Build/Target/Stop | 7,915.979 | dotnet (21624) | 101.780 | RazorCoreCompile

Regression:

Event Name | Time MSec | Process Name | DURATION__MSEC | targetName
Microsoft-Build/Target/Stop | 5,206.817 | dotnet (22608) | 506.903 | CoreCompile
Microsoft-Build/Target/Stop | 5,585.427 | dotnet (22608) | 241.141 | _GenerateScopedCssFiles
Microsoft-Build/Target/Stop | 4,544.413 | dotnet (22608) | 202.694 | ResolveAssemblyReferences
Microsoft-Build/Target/Stop | 4,075.320 | dotnet (22608) | 191.395 | Restore
Microsoft-Build/Target/Stop | 5,326.960 | dotnet (22608) | 119.798 | _CreateAppHost
Microsoft-Build/Target/Stop | 5,701.839 | dotnet (22608) | 97.088 | RazorCoreCompile

I can share traces if it’s helpful.

cc: @DamianEdwards, @stephentoub

[captainsafia]

https://github.com/dotnet/sdk/pull/16110 should resolve this. Waiting for this to flow to the installer to double confirm…

[captainsafia]

Tracked down the issue here.

So, in response to some feedback from the compiler team, we changed some of the caching logic that we use in the Razor source generator from leveraging a file-based cache to an in-memory cache. As part of this work, we leverage the module version ID as a unique identifier for values in the cache. The perf hit that we are seeing here is primarily a result of computing this identifier for assembly references in the current compilation. We incur this cost regardless of whether or not there is a cache hit/miss because the identifier is needed to resolve items in the cache.

With that in mind, I’m closing this issue as no-action for now for a couple of reasons:

• Although this is a perf regression between preview2 bits, there’s still a pretty solid perf improvement between .NET 5 (our baseline) and 6.0.100-preview.3.21153.9.
• We’ll eventually be replacing our caching mechanism by one provided by the compiler so this is a transient issue until we consume the right APIs.
• We’re trying to avoid filesystem interaction in the source generator so we can’t go back to our old caching strategy.