डॉटनेट कोर 2 लंबे समय तक पुनर्स्थापित समय की वजह से लंबे समय तक निर्माण

Question

मैंने देखा कि डॉटनेट कोर 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 

लेकिन डॉटनैट भी 15 सेकंड पता चलता है:
मैं तो बहाल बिना की कोशिश की और यह बहुत तेजी से किया गया था।
क्या यह हो सकता है कि केवल इमारत ही समय में गिना जाए?
यह सुनिश्चित नहीं है कि सब कुछ पहले ही बहाल होने पर पुनर्स्थापना हमेशा धीमी क्यों होती है।

क्या अन्य तरीके हैं जिससे मैं भवन की प्रक्रिया को तेज कर सकता हूं? टेलीमेट्री अक्षम करें? (मैं ओएसएक्स का उपयोग कर रहा हूं, मेरा पर्यावरण विकास पर सेट है)

मैं 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 है: 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 इस्तेमाल किया एसडीके द्वारा परिभाषित ग्लोब पैटर्न के आधार पर संपूर्ण फ़ोल्डर संरचना स्कैन करता है। यह प्रत्येक परियोजना मूल्यांकन के लिए किया जाता है और NuGet पुनर्स्थापना कम से कम तीन पूर्ण मूल्यांकन ट्रिगर करने लगता है।

चूंकि यह बड़ी निर्देशिका स्कैन करने के लिए धीमी है, SDK कुछ ज्ञात बड़ी निर्देशिका है कि आमतौर पर (आदि node_modules, bower_components) वैसे भी परियोजना के हिस्से के रूप में करना चाहता था नहीं कर रहे हैं छोड़ने के लिए किया पैटर्न ग्लोबिंग परिभाषित।

यह ज्ञात है कि विशेष परिस्थितियां इन अनुकूलन को बाधित कर सकती हैं या यहां तक ​​कि ग्लोब पैटर्न विस्तार/मिलान को शामिल/बहिष्कृत करने में प्रदर्शन कीड़े को ट्रिगर भी कर सकती हैं।

एहतियात के तौर पर (एक <PropertyGroup> तत्व के अंदर) DefaultItemExcludes संपत्ति को बाहर रखा जाना करने के लिए जाना सभी फ़ोल्डर जोड़ें:

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

Answer 2

मेरे लिए excluding.git फ़ोल्डर चारों ओर 10x तेजी से निर्माण करने के लिए मदद की।

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