RoutePatternAnalyzer (ASP0017, ASP0018) performance issue (1.5 minute execution time)

[TwentyFourMinutes]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

For roughly 2.5 weeks now I am experiencing extremely slow build times. dotnet build says that Core Compile takes forever here. Through the MSBuild Structured Log Viewer I was able to track down a few analyzers:

I can't really tell why this is happening.

Disabling analyzers on the project DOES help:

    <RunAnalyzersDuringLiveAnalysis>False</RunAnalyzersDuringLiveAnalysis>
    <EnforceCodeStyleInBuild>False</EnforceCodeStyleInBuild>
    <EnableNETAnalyzers>False</EnableNETAnalyzers>

Expected Behavior

Better performance.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

8.0.200-preview.23624.5

Anything else?

Microsoft Visual Studio Professional 2022 (64-bit) - Preview
Version 17.9.0 Preview 5.0

<TargetFramework>net8.0</TargetFramework>

[danmoseley]

Can you selectively disable the analyzers to find which one? Is it possible to reduce the relevant code to get an idea whether there's some part that's causing the slowdown?

[TwentyFourMinutes]

@danmoseley Disabling via the editor config or what do you have in mind? Reducing the code is somewhat hard. However removing EF Core migration from the compilation via <Compile Remove="Migrations/**" /> improves the speed significantly (down to 10s-30s)!

Edit: It makes sense to me that removing the migrations improves the performance as ASP0017/ASP0018 both target lambda expressions. In my instance the migrations directory contains a whopping ~22k lambdas.

[captainsafia]

@jaredpar @cston This seems similar to the issues that we were looking at recently. I believe we diagnosed it down to a compiler regression. Do you think this is related based on the details we have?

[jaredpar]

@captainsafia thus far we haven't found any compiler regressions. For a bit we thought there was a tier'd JIT issue but that is looking less likely. This looks like a case where i'd start by taking a look at the ETL and see what is taking time up in the analyzer.

[TwentyFourMinutes]

Would it be of any help to send binlogs or complogs?

[jaredpar]

A complog would definitely help here.

Note: complog will effectively send your entire project source so if that is non-public please file a VS feedback issue so you can share it privately.

[TwentyFourMinutes]

@jaredpar Thank you, I am aware of this. Sadly I am not able to open a Visual Studio Feedback, as the Web-App keeps telling me that VS is not connected. I already tried through the VS Installer as well, as well as logging out and in again. Is there a way to open a ticket without VS being "connected"?

[captainsafia]

@TwentyFourMinutes AFAIK, issues like this might be related to anti-virus/proxies/etc running on your machine that might interfere in the connection between VS and your browser. Do you suspect that might be at play?

You mentioned that the issue starts to happen about 2.5 weeks ago. Do you recall making any version updates or changes around that time?

[TwentyFourMinutes]

@captainsafia Effectively the only thing that might interfere here is either Bitdefender or Brave. Anyhow I also once disabled the Bitdefender AV in the settings. No proxy or anything else that should interfere. However I'll check again tomorrow.

The only "big" changes were:

• Moving from .NET 7 to 8. Note that I am only experiencing this issue in my .NET 8 ASP.NET app and not in comparable .NET 7 apps. Might be a coincidence though.
• Installing a Windows Dev Drive with a .vhdx partition and moving my global .NET Cache into the new partition (env. variable). (The affected project currently resides on this partition, however I experience the same issue on my native disk. Also a college on ubuntu seems to have a similar issue with the same project.)
• Enabling the new Terminal Logger by default through the env. variable.
• Update the Visual Studio Preview once or maybe twice.

Its very hard to say which one caused the issue in particular as I did all of these changes in close proximity to each other.

On a different note I could checkout the affected project directly pre/post the .NET 8 update (again, I think I tried it before with the same poor performance on both versions, HOWEVER I definitely didn't pin the SDK version with a global.json) to see if there is any difference.

[JamesNK]

Should be fixed by #54479