Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Tracking] Overhead of SDK build targets is too high for a normal build #1534

Closed
davkean opened this issue Aug 24, 2017 · 1 comment
Closed
Milestone

Comments

@davkean
Copy link
Member

davkean commented Aug 24, 2017

This is a normal build version of #1496 with a single project targeting .NET Core 2.0, running on 15.3.2:

msbuild "C:\Users\davkean\Source\Repos\ConsoleApp90\ConsoleApp90\ConsoleApp90.csproj" /clp:Summary;PerformanceSummary;v=m
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

</Project>

Comparing it against a default .NET Framework 4.6.2 project, it is 100% slower (620ms vs 311ms) on an up-to-date build:

This does not include:

  • Evaluation time
  • MSBuild launch time
  • Restore time
Time Target # Added in 15.3/2.0 Owner Bug Notes
620 ms Total 1 calls
211 ms ResolveAssemblyReferences 1 calls MSBuild dotnet/msbuild#2440, https://github.com/dotnet/core-setup/issues/3297 This is 30% slower than targeting 1.1 due to # of assemblies
124 ms ReportAssetsLogMessages 1 calls I believe majority of this is #1483
50 ms _CollectTargetFrameworkForTelemetry 1 calls SDK #1535
34 ms RunResolvePackageDependencies 1 calls
21 ms CheckForImplicitPackageReferenceOverrides 1 calls
17 ms PrepareForBuild 1 calls
13 ms ResolveProjectReferences 1 calls
12 ms _HandlePackageFileConflicts 1 calls
10 ms ResolveLockFileReferences 1 calls
10 ms FindReferenceAssembliesForReferences 1 calls
9 ms _CleanGetCurrentAndPriorFileWrites 1 calls
8 ms RunProduceContentAssets 1 calls
7 ms CopyFilesToOutputDirectory 1 calls
6 ms _GetProjectReferenceTargetFrameworkProperties 1 calls
6 ms _ComputeLockFileReferences 1 calls
5 ms GenerateTargetFrameworkMonikerAttribute 1 calls
5 ms CoreCompile 1 calls
5 ms _SetEmbeddedWin32ManifestProperties 1 calls
5 ms _ComputeTFMOnlyFileDependencies 1 calls
4 ms _GenerateCompileDependencyCache 1 calls
4 ms _ComputeLockFileCopyLocal 1 calls
3 ms AssignTargetPaths 1 calls
3 ms _CheckForInvalidConfigurationAndPlatform 1 calls
2 ms SplitResourcesByCulture 1 calls
2 ms CheckForDuplicateItems 1 calls
2 ms _ComputeNETCoreBuildOutputFiles 1 calls
1 ms ResolveCodeAnalysisRuleSet 1 calls
1 ms IncrementalClean 1 calls
1 ms GetCopyToOutputDirectoryItems 1 calls
1 ms GetAssemblyVersion 1 calls
1 ms GenerateBuildRuntimeConfigurationFiles 1 calls
1 ms ExpandSDKReferences 1 calls
1 ms CreateGeneratedAssemblyInfoInputsCacheFile 1 calls
1 ms CoreGenerateAssemblyInfo 1 calls
1 ms CleanupEmptyRefsFolder 1 calls
1 ms _GenerateSatelliteAssemblyInputs 1 calls
1 ms _ComputeTransitiveProjectReferences 1 calls
1 ms _ComputeReferenceAssemblies 1 calls
1 ms _ComputeLockFileFrameworks 1 calls
@nguerrera
Copy link
Contributor

Fixed by #1857

GangWang01 pushed a commit to GangWang01/sdk that referenced this issue Jun 7, 2022
GangWang01 pushed a commit to GangWang01/sdk that referenced this issue Jul 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants