sdk: Slow performance using dotnet restore & build with deep folder structure

Steps to reproduce

Create a new .NET Core project

mkdir MyProject
cd MyProject
dotnet new mvc

Create an embedded client app using create-react-app

mkdir client
cd client
create-react-app .

Restore the .NET Core application

cd ..
dotnet restore MyProject.csproj

Expected behavior

The expectation is that the restore should be very fast or at least as fast with the project.json version of the sdk.

Actual behavior

Restoring the application’s packages is terribly slow, probably due to the deep directory structure which node creates.

Environment data

dotnet --info output: .NET Command Line Tools (1.0.0-rc4-004771)

Product Information: Version: 1.0.0-rc4-004771 Commit SHA-1 hash: 4228198f0e

Runtime Environment: OS Name: Mac OS X OS Version: 10.12 OS Platform: Darwin RID: osx.10.12-x64 Base Path: /usr/local/share/dotnet/sdk/1.0.0-rc4-004771

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 1
Comments: 20 (11 by maintainers)

Most upvoted comments

Assuming you only want to publish the built output and not all development folders, you can exclude folders from being published - including the node_modules folder. If I add: <DefaultItemExcludes>$(DefaultItemExcludes);client\node_modules\**</DefaultItemExcludes> as property, dotnet publish only takes 3.2 seconds instead of 15.

dasMulli on Feb 11, 2017

Looks like msbuild is taking long to expand the globs brought in via the web sdk. The targets themselves don’t take very long to run (note that I never ran restore or build, just clean):

MacBook-Pro:tmp martin$ time dotnet msbuild /t:Clean /nologo /clp:PerformanceSummary

Project Performance Summary:
       55 ms  /Users/martin/tmp/tmp.csproj               1 calls
                 55 ms  Clean                                      1 calls

Target Performance Summary:
        0 ms  Clean                                      1 calls
        0 ms  AfterClean                                 1 calls
        0 ms  PrepareProjectReferences                   1 calls
        0 ms  BeforeClean                                1 calls
        0 ms  CleanReferencedProjects                    1 calls
        0 ms  _SplitProjectReferencesByFileExistence     1 calls
        0 ms  _CheckRuntimeIdentifier                    1 calls
        1 ms  CleanPublishFolder                         1 calls
        3 ms  _GetProjectReferenceTargetFrameworkProperties   1 calls
        5 ms  CoreClean                                  1 calls
        6 ms  CheckForDuplicateItems                     1 calls
        8 ms  _CheckForUnsupportedTargetFramework        1 calls
        8 ms  _CheckForInvalidConfigurationAndPlatform   1 calls
       15 ms  CheckForImplicitPackageReferenceOverrides   1 calls

Task Performance Summary:
        0 ms  RemoveDuplicates                           1 calls
        0 ms  WriteLinesToFile                           1 calls
        1 ms  MakeDir                                    1 calls
        1 ms  ReadLinesFromFile                          1 calls
        1 ms  Delete                                     2 calls
        1 ms  FindUnderPath                              2 calls
        1 ms  MSBuild                                    1 calls
        2 ms  Message                                    2 calls
        6 ms  CheckForDuplicateItems                     3 calls
        7 ms  CheckForImplicitPackageReferenceOverrides   1 calls

real	0m9.992s
user	0m6.952s
sys	0m3.141s

If I add <EnableDefaultItems>False</EnableDefaultItems> to the project, the same invocation only takes a second (a tenth of the time).

dasMulli on Feb 10, 2017

Looks like this has been fixed in the web sdk for the upcoming release https://github.com/aspnet/websdk/blob/dev/src/ProjectSystem/Microsoft.NET.Sdk.Web.ProjectSystem.Targets/netstandard1.0/Microsoft.NET.Sdk.Web.ProjectSystem.props#L15

dasMulli on May 1, 2017

Yes, clean has the same behaviour… dotnet clean

vlesierse on Feb 10, 2017