performance - dotnet core 2 long build time because of long restore time -


i noticed building in dotnet core 2 seemed lot slower.
timing after build showed 'only' 15 seconds.
couldn't believe timed time.

> time dotnet build microsoft (r) build engine version 15.3.409.57025 .net core copyright (c) microsoft corporation. 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 

that seemed more correct. minute.
tried without restore , lot faster:

> time dotnet build --no-restore microsoft (r) build engine version 15.3.409.57025 .net core copyright (c) microsoft corporation. 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 

but dotnet shows 15 seconds.
building counted in timings?
not sure why restore slow when restored.

are there other ways speed building process? disable telemetry? (i'm using osx, environment set development)

i prefer use dotnet watch run seems slower. running dotnet watch view parameters taking 12 seconds.

> 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 

is on system?

update:

here result dotnet restore /clp:performancesummary

> dotnet restore /clp:performancesummary   restore completed in 43.95 ms /users/roeland/dev/hrm/hrm.csproj.   restore completed in 52.73 ms /users/roeland/dev/hrm/hrm.csproj.   restore completed in 38.48 ms /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 

long story short: msbuild scans entire folder structure based on glob patterns defined sdk used. done each project evaluation , nuget restore seems trigger @ least 3 full evaluations.

since slow scan large directories, sdks define globbing patterns used exclude known large directories not wanted part of project anyway (node_modules, bower_components etc.).

it has been known special circumstances may circumvent these optimisations , or trigger performance bugs in include/exclude glob pattern expansion / matching.

as precaution, add folders known excluded defaultitemexcludes property (inside of <propertygroup> element):

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

Comments

Popular posts from this blog

What is happening when Matlab is starting a "parallel pool"? -

angular - DownloadURL return null in below code -

php - Cannot override Laravel Spark authentication with own implementation -