runtime: Most of libs partition is not incrementally buildable

I had some time during my vacation and stumbled upon this problem and submitted the following PRs to fix that:

• https://github.com/dotnet/runtime/pull/64000
• https://github.com/dotnet/runtime/pull/64037
• https://github.com/dotnet/runtime/pull/64041

I also filed https://github.com/dotnet/sdk/issues/23517 which causes 111 seconds being spent on re-validating something that shouldn’t run in an incremental no-op packaging operation.

EDIT: With all these changes combined (including https://github.com/dotnet/arcade/commit/8c1b3ebd48e863ecad85380d6509fba7076917f7 and https://github.com/dotnet/arcade/commit/1c78e4313e8dc240587f95938e8dcb298d1379d4 which make the build even faster), a libraries subset no-op incremental build (without tests) only takes 70 seconds on my Surface Book 2. On a dev PC tower probably less than a minute.

Here are the remaining Top 10 running tasks:

Summary:

• Restore could be bit faster in no-op scenarios (cc @jeffkl)
• RAR takes more than 5 seconds but considering that we are building 300+ projects incrementally it doesn’t seem that much. This data might still be interesting to folks like @rainersigwald and @dsplaisted.
• The no-op invocation of Ninja which detects no changes takes quite long. AFAIK shelling out into the Dev Command Prompt strongly contributes to this number. cc @jkoritzinsky for ideas how to improve this.
• The custom libraries binplacing and TargetFramework.Sdk logic adds a bit to the no-op build. I’m wondering why this is the case when nothing needs to be copied. The TargetFramework.Sdk overhead is likely due to this MSBuild target. cc @ericstj

Well I think the long pole is how long its taking to evaluate the projects:

Evaluated 1686 project(s) in 13603ms (1686 builds, 0 failures).

When I developed static graph-based restore, I was using a project tree with 750 projects which took 4 seconds to do a no-op restore. This repo is 1,686 projects and is taking 13.6 seconds (8ms per project on average). That is pretty darn fast in my opinion 😃 The NuGet side of things is only taking 3 seconds to determine that everything is up-to-date.

MSBuild does not cache evaluations from build to build so I’m not sure how to make this faster. We’d have to look at evaluations to see if we could speed it up. Static graph-based restore disables globs (stuff like *.cs) so that’s unlikely causing slowness. The evaluations and builds also very parallel but if the project tree’s dependencies are in declared in such a way, we could see less parallelism. @rainersigwald what’s your opinion, is there anything we can do to make evaluating 1,686 projects faster than 13 seconds?