efcore: Large compile-duration regression after upgrade from EF Core 3.1.0 to 3.1.1

I have not yet tried to reproduce this on a public repository, but I hope the problem is simple enough that that’s not an issue; I’ll try to make a repro asap.

Reproduction is timing compilation of a 16-project solution via dotnet msbuild bla.sln -target:restore;rebuild -verbosity:minimal -p:configuration=Release.

When the only project in that solution that depends on EF core contains the line <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.1.0" />, compilation takes approximately 21s (with sub-second standard deviation when the initial uncached build outlier is omitted.

When that dependency line is updated to <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.1.1" /> the build takes approximately 30s.

The effect appears to occur even on an almost empty solution too, but we’re still internally investigating whether that’s statistical noise or something significant (if I find out I’ll post that here).

Further technical details

EF Core version: 3.1.0 -> 3.1.1 Database provider: compile time, likely not relevant, but SQL Server Target framework: netcoreapp3.1 Operating system: windows 10 IDE: none.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 34 (27 by maintainers)

Commits related to this issue

Try with a global.json as per https://github.com/dotnet/efcore/issues/19597#issuecomment-575281772 Results: ``` Release310Rebuild: 0.8812637200000001 +/- 0.009853977278622115 seconds (including best... — committed to progressonderwijs/EfCoreCompileBench by EamonNerbonne 4 years ago

Most upvoted comments

@sanjaydebnath You can also try using the following new feature to explicitly mark certain files or folders as generated code in .editorconfig and exclude all analyzer execution for it: https://docs.microsoft.com/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#configure-generated-code

mavasani on Jun 26, 2020

This would also be a problem if you’re using two different versions in the same build, but that could produce many problems in the same vein – you would basically be defeating the cache by having an oversized working set.

agocke on Feb 3, 2020

Tagging @agocke for thoughts on the compiler server here.

Pilchie on Jan 31, 2020

I did some more digging into this and discovered something very interesting. If one shuts down the dotnet SDK build server between runs, there no longer seems to be any difference between the build times. Here’s a sample run on my Linux machine:

➜  Project310 git:(master) ✗ dotnet build-server shutdown; dotnet build > /dev/null; grep version ../global.json; hyperfine --warmup 3 "dotnet build --no-incremental --no-restore"
Shutting down MSBuild server...
Shutting down VB/C# compiler server...
VB/C# compiler server shut down successfully.
MSBuild server shut down successfully.
        "version": "3.1.100",
Benchmark #1: dotnet build --no-incremental --no-restore
  Time (mean ± σ):      1.169 s ±  0.083 s    [User: 1.507 s, System: 0.175 s]
  Range (min … max):    1.077 s …  1.328 s    10 runs
 
➜  Project310 git:(master) ✗ cd ../Project311 
➜  Project311 git:(master) ✗ dotnet build-server shutdown; dotnet build > /dev/null; grep version ../global.json; hyperfine --warmup 3 "dotnet build --no-incremental --no-restore"
Shutting down MSBuild server...
Shutting down VB/C# compiler server...
MSBuild server shut down successfully.
VB/C# compiler server shut down successfully.
        "version": "3.1.100",
Benchmark #1: dotnet build --no-incremental --no-restore
  Time (mean ± σ):      1.162 s ±  0.086 s    [User: 1.507 s, System: 0.185 s]
  Range (min … max):    1.110 s …  1.394 s    10 runs

In other words, it would seem like building with one version of the analyzer somehow leaves some state behind (at the build server), which adversely affects the perf of another run using a different version of the analyzer. @EamonNerbonne / @ajcvickers / @rainersigwald as these are weird results it would be great for someone to reproduce them.

Should I open a new issue with the Roslyn team (anyone in particular)?

PS I’ve seen this behavior on both Linux and Windows PPS I also did an IL comparison between the two version (3.1.0/3.1.1) of Microsoft.EntityFrameworkCore.Analyzers.dll from the nuget packages, and apart from versioning differences they are identical.

roji on Jan 31, 2020