Open ShreyasJejurkar opened 1 year ago
I took a first pass at this just now. I used a different 8.0 preview, and I got a slightly smaller difference between 8.0 and 7.0, but it was still very measurable—over 40% slower.
I compared binlogs from the build part, and build was about 50% slower. Drilling down, the csc task was driving the difference: net8:
net7:
Glancing through the parameters, the parameter that jumped out at me is that net8 has a new analyzer: Microsoft.Interop.ComInterfaceGenerator.dll
@jaredpar, is there some way I can measure the performance of that analyzer? Happy sharing binlogs or whatever other information you think might be useful in looking into this.
@Forgind
Yes pass -p:ReportAnalyzer=true
to dotnet build
and then there will be a summary of analyzer / generator time included in the binlog. It will make it very evident how much time is spent in every assembly and individual analyzer / generator.
Well, the good news is that the analyzer is indeed part of the problem; the analyzers for net8 took about 2.5x as long as for net7. The bad news is that that only accounts for about a third of the discrepancy, so there's likely something else going on here. net7.txt net8.txt
I attached a binlog (just change the extension) with analyzer times included for each of net7 and net8. This is the first build experience without the compiler server (or dotnet, etc.) running. You can see that there's about a one-second difference in Csc execution time, which mostly accounts for the total difference in build time (and the rest is likely noise), and about 0.3 seconds of that is from analyzers.
Assigned to @cston to investigate.
This might be just because there are new analyzers in .NET 8
This might be just because there are new analyzers in .NET 8
Agreed. But my question is why those new analyzers are running for a simple "Hello World" program. Newcomers are usually ones who will run this program as their first one, when they see slowness in the compilation itself (if they compared it to what others offer), they will lose motivation for learning .NET there itself.
Glancing through the parameters, the parameter that jumped out at me is that net8 has a new analyzer: Microsoft.Interop.ComInterfaceGenerator.dll
One more thing what this analyzer is getting invoked for a simple hello world program? Is it like code under hood is having com interop? i mean Console.WriteLine
?
Moving to roslyn-analyzers
I'm seeing something similar. Our builds on some developer machines are very slow. The build log shows that almost all the time is spent in the Csc tasks. A large portion of the time is spent in the ComInterfaceGenerator. For one project, the time in Csc was 5+ minutes(!) and the time in ComInterfaceGenerator was 2 minutes even though the project does no COM interop(!). I tried removing that analyzer using a custom target:
<Target Name="DisableSlowAnalyzers" BeforeTargets="CoreCompile">
<!-- Building using .NET 8 seems to sometimes be very slow with a lot of time spent in the COM interop generator, which we don't use. Disable it. -->
<ItemGroup>
<Analyzer Remove="@(Analyzer)" Condition="'%(Analyzer.Filename)' == 'Microsoft.Interop.ComInterfaceGenerator'"/>
</ItemGroup>
</Target>
Even with that analyzer removed, the build was still MUCH slower than before we moved to .NET 8. The behavior is not consistent. Some developers experience the build slowness and others don't. So far, none of our (10) CI servers has shown this problem.
The behavior is not consistent. Some developers experience the build slowness and others don't. So far, none of our (10) CI servers has shown this problem.
This part is very interesting to me. Perhaps there's some extra feature turned off in CI that makes builds unimaginably slower? The only feature I'm aware of is MSBuild's new terminal logger, but I'd be very, very surprised if that was the problem, especially since most of the problem is driven by csc. Is anyone aware of other features turned on by default but turned off in CI?
I tried the following with SDK versions 7.0.313 and 8.0.200:
> dotnet new console
> Measure-Command -Expression { dotnet build /t:rebuild }
> Measure-Command -Expression { dotnet build /t:rebuild }
> Measure-Command -Expression { dotnet build /t:rebuild }
> ...
Ignoring the first Measure-Command
run in each case, the times varied between runs with either SDK but the times seemed to be in a similar range across the two SDKs: 50ms - 150ms.
I was just trying to compiler and run a simple console hello world project, and noticed that the
dotnet build
anddotnet run
commands are performing very slowly. So I tried with .NET 7 as well with version7.0.203
and those are pretty fast as 2x compared to .NET 8.Please see the command output for more detail. I tried many times but every time .NET 7 builds times faster than .NET 8. Even the
dotnet new console
command is slow compared to .NET 7.So looks like something is wrong there or the code has regressed.
.NET 7
.NET 8