.NET Core/.NET Standard build performance #2789
Comments
davkean
added
the
Tracking
|
Should we like this to the issue on MSBuild for RAR perf too? |
|
Targets, including RAR, are linked from Overhead of SDK build targets is too high for a normal build. |
|
There's dotnet/msbuild#2015 too |
|
Hmm, need to understand why dotnet/msbuild#2192 hasn't moved the mile - does it only kick in on the .NET Core build? |
|
Here is a real world example of the difference between the two web sites building on VS 2017 15.3.4 with an SSD. Full clean was performed before running each test of a full solution rebuild (including the test projects): Solution A (.NET Framework 4.7, 2,555 .cs files, 20 projects) - rebuild time 0:31 Solution B (.NET Core 2.0, 827 .cs files, 19 projects) - rebuild time 2:13 (1:44 with ESET AV 6.5.2107.1 disabled). |
Fixes: dotnet#2434 Partially fixes: dotnet#2429 This change converts MSBuildNameIgnoreCaseComparer to a stateless comparer by implementing IConstrainedEqualityComparer, this avoids: 1. Creating a new comparer for every collection (saves ~1% of allocations) 2. Locking within Equals/GetHashCode (saves ~0.2% of allocations) This saves approx 300ms running a design time build over the project called out in dotnet/project-system#2789.
|
Moving remaining work to 15.6. |
|
The efforts so far have lead to a significant improvement for incremental builds!
Thanks for the continued effort! ❤️ 🍻 |
|
@dasMulli Thanks! As you can see, we're making some pretty significant progress in 2.2 - more coming. |
|
@davkean It seems there is one very good test of build infrastructure performance using dotnet coreclr repo : dotnet/msbuild#2843
|
|
@4creators At the moment we're focusing on reducing process overhead (enabling the C# compiler server and also MSBuild node reuse on .NET Core/dotnet). Afterwhich we're looking at reducing up-to-date builds. It would be interesting to see if CoreCLR's issues are due to their custom build or just merely MSBuild overhead. I suspect both are at fault. |
|
Moving to 15.7. We've made a lot of progress here in 15.6, and more is already underway for 15.7. However, we also need to take stock and re-evaluate/re-profile to see what the current largest costs are. |
|
Thanks for all the work that landed in 2.1.0-preview1, It's highly appreciated! I'd actually like to help with a few of these issues so new info around latest hotspots is very welcome, as it's hard to profile on osx. |
|
As a heads up, more improvements have been made in Preview 2 - https://blogs.msdn.microsoft.com/dotnet/2018/04/11/announcing-net-core-2-1-preview-2/.
|
|
At this point, we've spent a large effort improving performance across build, solution load, branch switching and few other areas for VS 15.5, 15.6, 15.7 and continuing to do so in 15.8. Post 15.8 it will continue to be a focus. At this point, this overarching bug has now outlived its usefulness and we're no longer using it to drive issues. Each individual issue that it pointed out has individual bugs and we'll be using those to track them. |
|
Agreed. Thanks for all the hard work on this. Performance is orders of magnitude better now. |
This is an overarching issue that I'm using to track evaluation/build performance issues across all repos. This has a .NET Core/.NET Standard focus, but due to overlap, improvements such as dotnet/msbuild#1276, will improve all project types.
Notes:
Evaluation
Long evaluation times increases almost all scenarios including project load, adding/removing files, build, time-to-intellisense. Because both project systems will block the UI thread waiting for this - single project evaluation should be 20-50 ms.
CPU Time
Breakdown: Overhead of evaluation is too high for design-time build
30-50%For large projects with globs, MSBuild takes up to 30% - 50% of a build searching the disk10-60%Avoid double evaluation of all ProjectReferencesIn PR: dotnet/msbuild#2595.30-50%Early evaluation of invalid DefaultCompileItems recursive itemgroup performance issue during incremental builds9-20%Adding .NET Standard reference assemblies is consuming lots of time in buildPerformance inside Project.GetAllGlobs0-13.0%Normalize include and exclude specs before file walking10%Optimize away separate evaluation for /restore when the restore didn't actually pull down new props/targetsCLI1.4%Calculating $(FrameworkPathOverride) takes up to 1.4% of evaluation of a solution-wide design-time build1.3%Calculating $(CodeAnalysisPath)/$(CodeAnalysisStaticAnalysisDirectory) in Microsoft.CodeAnalysis.targets takes up 1.3% of evaluation of a solution-wide design-time build1.0%Resolving ToolsVersion costs 1% of a build and 2% of all allocations0.9%MSBuild is still opt'ing into the legacy GetFullPath behavior0.5%Calculating whether a .NET Standard library ref is a facade costs 0.5% of solution-wide design time buildMemory
2.6 - 5.5%ItemFragment.CreateFileMatcher allocating 2.6% of solution-wide design-time build just getting directory name3.0%Reduce allocations in ExpandExpressionCaptureIntoStringBuilder2.7%FileMatcher is allocating twice it needs to due to using Directory.GetFiles/GetDirectories2.4%Large allocation via GetEnvironmentVariables2.0%Resolving ToolsVersion costs 1% of a build and 2% of all allocations0.5% - 1.7%Globbing is boxing enumerators causing 0.5% of all allocations opening solution2.0%ProcessItemSpec allocating 2.0% of all allocations%0-2.0%Avoid iterator/list allocations when parsing projects1.6%Remove short-lived List allocations from SplitSemiColonSeparatedList1.5%Do not allocate in TaskItem.GetHashCode0.4 - 1.4%Large amount of allocations during evaluation due to boxing of KeyedObject1.4%Reduce allocations in Lookup.GetItems1.3%Updating conditioned properties is adding 1.3% of evaluation allocations1.2%Unnecessary List instantiation1.0%Getting filename/extension metadata allocations 1% of solution-wide design-time buildMSBuildAll1.0%MSBuildNameIgnoreCaseComparer is allocating 1% of a solution-wide design-time build0.8%ProjectInstance.GetItemsByItemTypeAndEvaluatedInclude allocates ~0.8% of open solution0.7%TaskItemSpecFilenameComparer.Compare allocations 0.7% of a solution-wide design-time build0.4%Remove unneeded allocations in ItemSpec.MatchesItem0.2%Remove enumerator boxing0.2%Remove boxed enumerator allocationBuild
Long build times increases F5, project load (legacy), editing (legacy) and time-to-intellisense. Because the legacy project system blocks the UI thread waiting for this - a single project design-time build should be 100-200ms.
CPU Time
Breakdown (design-time build): Overhead of SDK build targets is too high for design-time builds
Breakdown (normal build): Overhead of SDK build targets is too high for a normal build
25%improve NuGet.targets perf for implicit restore20%Use msbuild /restore instead of a separate process12%Add reference metadata to indicate that RAR can skip dependency searching5%5% of a build is due ResolveAssemblyReferences's cache checking0.1%GetInstalledSDKLocations runs in every project regardless of whether they even target a Windows SDKTwo versions of JSON.NET are being loaded during a build.NET Core-based projects are not using the RAR cache in design-time buildsMemory
20%Reduce AssemblyName allocations11%Avoid cloning AssemblyName6.5%ResolvePackageDependencies is producing 6.5% of allocations in a build3.7%FileUtilities.HasExtension allocating 3.7% of a solution build3.7%ResolveNuGetPackageAssets allocates 3.7% of solution-wide design-time build3.3%ConflictResolver.ResolveConflict is ~3.3% of all allocations in solution-wide design-time build0.3%NuGet.ProjectModel reads column/line information producing 15 MB of unneeded garbageCustomer action items:
<PackageReference/>to NETStandard.Library.NETFramework - this has been replaced with functionality as part of .NET Core 2.0 SDK.The text was updated successfully, but these errors were encountered: