runtime: Clean build takes too long
On current master (https://github.com/dotnet/runtime/commit/7f52377bbcbb90e7b104e97505866320accae060) on Windows 10.0.19546 prerelease 200110-1443, SurfaceBook 2 13’’ (Surface_Book_1832) it took 38 minutes to run a clean build (build -subsetCategory coreclr-libraries -runtimeConfiguration Release
). The task itself reports only Time Elapsed 00:31:22.36
, my guess is that the additional time is spent on restoring the build tools.
I ran the same on my personal Linux machine (PC not a notebook; Manjaro 19.0.2 Kyria kernel x86_64 Linux 5.5.7-1; Intel Core i7-4771 @ 8x 3.9GHz) and it took 19 minutes, reported 15:44:45.
Note that my PC is ~6yo, mid-level budget, custom build machine, nothing fancy.
I can share binlogs from both runs, but they’re too big to attach here.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 26 (26 by maintainers)
ProgressReference = 'SilentlyContinue
means it will to report progress which considerably slows down the download. It already is in use for the download dotnet-install.ps1(105).I’ll try that, that seems promising 👍
I do build only clr and libs, i.e.:
build -subset clr+libs -runtimeConfiguration Release
. I do run libraries tests all the time, but I’ll try the subset you’re suggesting (clr.runtime+clr.nativecorelib+libs.pretest
).Thanks a lot!
@akoeplinger mono build is quite faster! 👍 22 minutes including the initial download, 12 minutes reported by the build. Since the libraries themselves take around 10 minutes it means that mono is build much much faster than clr! I’d have to rerun it for just runtimes but my guesstimate is that mono build is 5-7 times faster than clr.
You only need to build coreclr to run tests. To build and get yourself unblocked you can just build
-subset coreclr.corelib
.However I think we should strive towards building faster, we’re doing investigations to improve that.
@ManickaP I wonder if your nuget cache was not populated and you had to hit the network for all the packages, also note that we removed some of the restore sources and are relying on Azure feeds which have throttled us and also have been having some hicups. It would be good to clean your repo and trying again to see how it goes. Also, building just libraries (first coreclr or just corelib) and then measure the build time for just libraries, in CI, and others machine the restore change made the build faster because we changed the way we restored.
Build command
Build times in minutes:
Observations
Coreclr build parallelizes significantly better on unix, and runs ~3x faster. My guess is that this is because we have to fan out and fan back for each subproject we build.
That’s because of the way Arcade builds the passed in
$(ProjectToBuild)
items. We should set theStopOnFirstFailure
property in the msbuild task in Arcade via an extension point: https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/Build.proj#L249. I think @akoeplinger mentioned the same thing some weeks ago.@jashook I’m aware of that. My main point is: please don’t make it any slower and if possible make it faster. SB is my main work machine, I have to live with those 38 minutes.