dotnet core 2由于恢复时间长,构建时间长

Question

我注意到在dotnet core 2中构建的速度似乎要慢得多.
但是构建之后的时间总是显示"仅"15秒.
我简直不敢相信,所以我把它计时了time.

> time dotnet build
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  hrm -> /Users/r/dev/hrm/bin/Debug/netcoreapp2.0/hrm.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:15.45

real    0m52.366s
user    0m36.851s
sys     0m15.458s

这似乎更正确.差不多一分钟.
然后我尝试了没有恢复,它更快:

> time dotnet build --no-restore
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  hrm -> /Users/r/dev/hrm/bin/Debug/netcoreapp2.0/hrm.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:15.39

real    0m15.795s
user    0m11.397s
sys     0m4.238s

但是dotnet也显示了15秒.
难道只有建筑才算在计时中吗？
一切都已恢复,不确定为什么恢复总是很慢.

还有其他方法可以加快建设过程吗？禁用遥测？(我正在使用osx,我的环境设置为开发)

我更喜欢使用,dotnet watch run但似乎更慢.运行dotnet watch以查看参数需要12秒.

> time dotnet watch
Microsoft DotNet File Watcher 2.0.0-rtm-26452

Usage: dotnet watch [options] [[--] <arg>...]

Options:
  ....


real    0m12.631s
user    0m8.880s
sys     0m3.816s

这只是在我的系统上吗？

更新:

以下是dotnet restore/clp:PerformanceSummary的结果

> dotnet restore /clp:PerformanceSummary
  Restore completed in 43.95 ms for /Users/roeland/dev/hrm/hrm.csproj.
  Restore completed in 52.73 ms for /Users/roeland/dev/hrm/hrm.csproj.
  Restore completed in 38.48 ms for /Users/roeland/dev/hrm/hrm.csproj.

Project Evaluation Performance Summary:
    36252 ms  /Users/roeland/dev/hrm/hrm.csproj          3 calls

Project Performance Summary:
    36424 ms  /Users/roeland/dev/hrm/hrm.csproj          9 calls
              24359 ms  Restore                                    1 calls
                  1 ms  _IsProjectRestoreSupported                 2 calls
              12011 ms  _GenerateRestoreProjectPathWalk            1 calls
                  1 ms  _GenerateRestoreProjectPathItemsPerFramework   1 calls
                 43 ms  _GenerateRestoreGraphProjectEntry          1 calls
                  0 ms  _GetRestoreSettingsPerFramework            1 calls
                  6 ms  _GenerateProjectRestoreGraph               1 calls
                  3 ms  _GenerateProjectRestoreGraphPerFramework   1 calls

Target Performance Summary:
        0 ms  _GenerateRestoreGraphProjectEntry          1 calls
        0 ms  _GenerateProjectRestoreGraph               1 calls
        0 ms  _GetRestoreTargetFrameworksAsItems         1 calls
        0 ms  _GetRestoreProjectStyle                    2 calls
        0 ms  CheckForImplicitPackageReferenceOverridesBeforeRestore   2 calls
        0 ms  _CheckForUnsupportedNETCoreVersion         1 calls
        0 ms  _IsProjectRestoreSupported                 1 calls
        0 ms  _GetRestoreSettingsPerFramework            1 calls
        0 ms  _GetProjectJsonPath                        2 calls
        0 ms  _GetRestoreSettingsOverrides               1 calls
        1 ms  _GenerateRestoreProjectPathWalk            1 calls
        1 ms  _GenerateRestoreProjectPathItemsPerFramework   1 calls
        1 ms  _GenerateRestoreSpecs                      1 calls
        1 ms  _GenerateRestoreProjectSpec                1 calls
        2 ms  _GenerateProjectRestoreGraphPerFramework   1 calls
        2 ms  _GetRestoreTargetFrameworksOutput          1 calls
        5 ms  _GenerateRestoreDependencies               1 calls
       10 ms  _LoadRestoreGraphEntryPoints               1 calls
       20 ms  _GenerateDotnetCliToolReferenceSpecs       1 calls
       21 ms  _GetRestoreSettings                        1 calls
       54 ms  _GenerateRestoreGraph                      1 calls
      216 ms  Restore                                    1 calls
    12007 ms  _GenerateRestoreProjectPathItems           1 calls
    12014 ms  _GetAllRestoreProjectPathItems             1 calls
    12058 ms  _FilterRestoreGraphProjectInputItems       1 calls

Task Performance Summary:
        1 ms  Message                                    3 calls
        1 ms  ConvertToAbsolutePath                      2 calls
        1 ms  GetRestorePackageReferencesTask            1 calls
        1 ms  GetRestoreProjectReferencesTask            1 calls
        2 ms  GetRestoreProjectFrameworks                1 calls
        3 ms  RemoveDuplicates                           5 calls
        4 ms  WarnForInvalidProjectsTask                 1 calls
       18 ms  GetRestoreSettingsTask                     1 calls
       20 ms  GetRestoreDotnetCliToolsTask               1 calls
      216 ms  RestoreTask                                1 calls
    36121 ms  MsBuild                                    9 calls

Answer 1

简而言之:MSBuild基于所使用的SDK定义的glob模式扫描整个文件夹结构.这是针对每个项目评估完成的,NuGet恢复似乎至少会触发三次完整评估.

既然是慢扫描大型目录,该SDK的限定通配符用于排除通常不希望作为该项目的一部分,反正(一些知名的大型目录模式node_modules,bower_components等等).

众所周知,特殊情况可能会绕过这些优化,甚至触发包含/排除glob模式扩展/匹配中的性能错误.

作为预防措施,将已知要排除的所有文件夹添加到DefaultItemExcludes属性中(在<PropertyGroup>元素内):

<DefaultItemExcludes>custom\node_modules\**;$(DefaultItemExcludes)</DefaultItemExcludes>

Answer 2

对我来说，排除 .git 文件夹有助于使构建速度提高 10 倍左右。

  <PropertyGroup>
    <DefaultItemExcludes>.git\**;$(DefaultItemExcludes)</DefaultItemExcludes>
  </PropertyGroup>