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
Post a Comment