Regression in New BlazorServer Template Build Time

[brianrob]

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

[brianrob]

@pranavkm, can you take a look please?

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[captainsafia]

@brianrob Can you share what versions are used for "baseline" and "regression" here? We've made a few changes in the Razor source generator over the past few days that might contribute to the deltas you are seeing.

[brianrob]

Per the this regression showed up in the installer in ec6da1cd62090.
The baseline is ec6da1cd62090. Here's a list of changes, which is basically just a pointer to the SDK update that was ingested. If you follow the link to the SDK, you'll find that there are a handful of components that were updated, a few of which are ASP.NET related.

[captainsafia]

dotnet/sdk#16110 should resolve this. Waiting for this to flow to the installer to double confirm...

[captainsafia]

I'm getting the following results on 6.0.100-preview.3.21153.9 on a fresh Blazor Server template. There's still some work to do on the CoreCompile target here.

       80 ms  RazorCoreCompile                           
      110 ms  _GenerateScopedCssFiles                  
      127 ms  Restore                                    
      130 ms  ResolveAssemblyReferences                
      503 ms  CoreCompile                               

[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.