dotnet core 2 długi czas budowy ze względu na długi czas przywracania

Question

Zauważyłem, że budynek w rdzeniu dotnet 2 wydawał się dużo wolniejszy.
Ale czas po kompilacji zawsze pokazywał "tylko" 15 sekund.
Nie mogłem w to uwierzyć, więc zaplanowałem to na 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 

To wydawało się bardziej poprawne. Prawie minutę.
Następnie próbowałem bez przywracania i to dużo szybciej:

> 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 

Ale DotNet pokazuje również 15 sekund.
Czy to możliwe, że tylko budynek jest liczony w czasie?
Nie wiem, dlaczego przywracanie jest zawsze wolne, gdy wszystko jest już przywrócone.

Czy są inne sposoby na przyspieszenie procesu budowlanego? Wyłączyć telemetrię? (Używam osx, moje środowisko jest ustawione na rozwój)

Preferuję używać dotnet watch run, ale wydaje się to nawet wolniejsze. Uruchamianie dotnet watch w celu wyświetlenia parametrów zajmuje 12 sekund.

> 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 

Czy to tylko w moim systemie?

Aktualizacja:

Oto wynik z dotnet przywrócić/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

Krótko mówiąc: MSBuild skanuje całą strukturę folderów na podstawie wzorców glob określonych przez SDK używany. Odbywa się to dla każdej oceny projektu, a przywrócenie NuGet wydaje się powodować co najmniej trzy pełne oceny.

Ponieważ skanowanie dużych katalogów jest powolne, zestawy SDK definiują wzorce globu używane do wykluczania niektórych znanych dużych katalogów, które i tak nie są pożądane jako część projektu (node_modules, bower_components itd.).

Wiadomo, że szczególne okoliczności mogą ominąć te optymalizacje, a nawet wywołać błędy wydajności w rozszerzeniu/dopasowaniu wzorca włączenia/wykluczenia globu.

Jako środek ostrożności, dodać wszystkie foldery znane mają być wyłączone z właściwością DefaultItemExcludes (wewnątrz elementu <PropertyGroup>):

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

Answer 2

Dla mnie excluding.git folderu pomogły uczynić build około 10x szybciej.

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