長い復旧時間のため、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 

これはもっと正しいようです。ほぼ1分。
私はその後、復元せずにしようと、それははるかに高速だった：

> 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 

これは私のシステムでのみですか？

アップデート：ここ

は/ CLPを復元DOTNETからの結果である：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のリストアは少なくとも3回の完全な評価を引き起こすようです。

大きなディレクトリをスキャンするのが遅いため、通常はプロジェクトの一部として望ましくない大規模なディレクトリ（node_modules、bower_componentsなど）を除外するために使用されるグロブパターンがSDKによって定義されています。

特別な状況では、これらの最適化を回避したり、包含/除外グロブパターンの拡張/マッチングでパフォーマンスのバグを引き起こしたりすることがあることが知られています。予防措置として

、（<PropertyGroup>要素の内側）DefaultItemExcludesプロパティに除外されることが知られているすべてのフォルダを追加します。

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

Answer 2

私にとってexcluding.gitフォルダには、周りの10倍速く構築するために役立ちました。

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