runtime: Clean build takes too long

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).

if you install the same version of dotnet SDK that we specify here in your machine and it is on the PATH

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.

I think it would be nice if the coreclr component can come pre-built or something One of the reasons why we merged the repos was to have a coherent up to date version and avoid having to wait for an official build to publish a version of coreclr, manage breaks, etc. Is something we could consider as an opt-in option.

However I think we should strive towards building faster, we’re doing investigations to improve that.

Today’s (214e207) numbers are 45 minutes for clean build build -subset clr+libs -runtimeConfiguration Release. I guess it has something to do with the recent work on restore.

@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.sh -subsetCategory coreclr-libraries -runtimeConfiguration Release .\build.cmd -subsetCategory coreclr-libraries -runtimeConfiguration Release

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.

incrementally rebuilding after a merge often fails; suspect we are missing dependencies somewhere, but haven’t bothered trying to figure out why. So I often end up needing to do full rebuilds.

That’s because of the way Arcade builds the passed in $(ProjectToBuild) items. We should set the StopOnFirstFailure 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.