我注意到在dotnet core 2中构建的速度似乎要慢得多
但是,构建之后的时间总是只显示出#39; 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
但是,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
这仅限于我的系统吗?
更新
以下是dotnet restore / 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
答案 0 :(得分:10)
长话短说:MSBuild基于所使用的SDK定义的glob模式扫描整个文件夹结构。这是针对每个项目评估完成的,NuGet恢复似乎至少会触发三次完整评估。
由于扫描大目录的速度很慢,因此SDK会定义用于排除一些通常不想作为项目一部分的已知大型目录的通用模式(node_modules
,bower_components
等)
众所周知,特殊情况可能会绕过这些优化,甚至触发包含/排除glob模式扩展/匹配中的性能错误。
作为预防措施,将已知要排除的所有文件夹添加到DefaultItemExcludes
属性中(在<PropertyGroup>
元素内):
<DefaultItemExcludes>custom\node_modules\**;$(DefaultItemExcludes)</DefaultItemExcludes>
答案 1 :(得分:3)
对于我来说,exclude.git文件夹有助于使构建速度提高约10倍。
<PropertyGroup>
<DefaultItemExcludes>.git\**;$(DefaultItemExcludes)</DefaultItemExcludes>
</PropertyGroup>