Make static graph restore the default experience.

[nkolev92]

This is an epic tracking all things relevant to static graph restore and whether there are any blockers/concerns to making it the default.

For readers, you'll need Zenhub to see the linked issues.

Currently this contains all potential issues tagged as static graph.

This doesn't mean they all need to be fixed, just analyzed :)

Note

For customers moving to static graph

• If you want to ensure that your restore is equivalent across static graph and regular restore consider running:

1. Restore with static graph.
2. Restore without static graph

When you run this, at the end of the second restore you should see something like:
All projects are up-to-date for restore.

• Static Graph restore won't warn for invalid projects #9300

[jeffkl]

One potential issue is that static graph evaluation based restore doesn't call any of the older targets like _GenerateRestoreProjectPathItemsPerFramework. People shouldn't be using them as extension points since we prefixed them with _ but there's no enforcement. So if the default switches, these targets won't run any more and people's builds can start failing in very weird ways.

Telemetry would help us greatly here to know how many people are doing this. We might even be able to add a warning in a future release telling people that the targets are going away.

[nkolev92]

That's a great point.
Definitely a smaller concern, but a possibility.

Think advertising the existence of the feature more broadly before making it a default is a good idea.

1ES repos will probably catch a large majority of the scenarios, but you can never have too many dogfooders :)

[jeffkl]

We are spinning up automation to make it the default for all 1ES customers by sending PRs to their repos. I'll update this issue with the problems we have getting people to adopt it.

[anangaur]

What's the trigger, criteria before we make this default?

[nkolev92]

The plan is to make it default in the next major release given that it's a big change.

The main criteria is correctness. We need static graph to not regress current functional scenarios.

Perf gains are something we'll look into (we have) as well, but numbers there have been overwhelmingly positive for large project counts, and on par for lesser project counts.

[nkolev92]

Note for other readers.

Static graph is pretty safe to use.
We've found a very limited set of issues and most of those fail fast.
Unless you are customizing restore somehow, switching to static graph should just work.

[aolszowka]

FWIW you may break others who have custom Project Types wherein static graph does not work, I have filed a bug report at #10019

[nkolev92]

@aolszowka The dup of the issue you linked in tracked here.

[nkolev92]

Oh @jeffkl is already on it!

[nkolev92]

I have updated the issue body calling out the way to test for the equivalence of these 2 experiences.

If you see a problem, do let us know by filling an issue.

[aolszowka]

What was the status on dog-fooding this? I can't believe we're this unique to have two issues found by just us #10307

[Piedone]

I've made some performance measurements, locally and under GitHub Actions (Ubuntu and Windows) with our Lombiq's Open-Source Orchard Core Extensions solution. This, since it uses Orchard Core, has hundreds of package dependencies with transitive ones included.

You can find my results here. I've seen some nice 8-15% speedups locally during dotnet restore. In GitHub Actions builds I was more interested in the overall impact on the dotnet build times (usually we don't have a separate restore) and while it does show up as a 0,5-4,5% speedup there too with an empty NuGet cache (what happens with GHA builds due to their fresh VMs, unlike local ones), the 3,5% slowdown for the full source Windows builds (which is the slowest) cancels out the aggregate compute time gains (and adds time waiting for the workflow to finish).

Could you check it out, please? It seems that turning this on doesn't help in the GHA case all in all. Though the margins we're talking about here are really small, so probably doing more measurements would turn the end result somewhat.

[jeffkl]

@Piedone thanks for the detailed performance measurements. During a full restore, I would not necessarily expect static graph-based restore to be too much faster. The main optimization that static graph-based restore uses is an out-of-proc system for evaluating all of the MSBuild projects which uses some special feature flags to improve performance as well as server GC. Once the projects have been evaluated, the same code runs to execute restore for both "regular" and static graph-based restore.

The more projects a repository has, the more I would expect static graph-based restore to speed things up. And of course no-op restores benefit the most since evaluating all of the MSBuild projects is the long pole and no packages are pulled and unzipped. For example, we have an internal repo with 750 projects where a full no-op restore used to take 35 seconds but now takes only 7 seconds. We also have a repository with 5,000 projects that would basically time out when restoring but now can restore in a few minutes.

We'll continue to improve restore performance in both scenarios and see if we can ever make static graph-based restore the default. But for now it will remain opt-in based on each individual repositories needs.

[Piedone]

I see, thanks for the explanation!

[ghost]

Issue is missing Type label, remember to add a Type label

[stan-sz]

Just in case, linking dotnet/msbuild#8326