Restore in VS: For CPS based PackageReference projects investigate improving the up to date check by utilizing the fact that the project cache + settings might not have changed since last restore

[nkolev92]

Related to https://github.com/NuGet/Home/blob/dev/designs/VisualStudio-PartialRestoreOptimization.md, #9513.

In here we skip if the effective package spec + outputs are up to date and same as last time.

A further optimization would be to avoid creating an effective dg spec (which combines the setting + package spec) if the settings are the project system cache are not updated.

• At this point, it can/would only apply to SDK based projects/solutions
• Note we can't skip it for mixed solutions because of transitivity

[nkolev92]

The 2 steps that we'd improve would be:

https://github.com/NuGet/NuGet.Client/blob/25ffb078df99a8d4b4c5026e9148edcd9e5f352b/src/NuGet.Clients/NuGet.SolutionRestoreManager/SolutionRestoreJob.cs#L374-L382

and part of

https://github.com/NuGet/NuGet.Client/blob/25ffb078df99a8d4b4c5026e9148edcd9e5f352b/src/NuGet.Clients/NuGet.SolutionRestoreManager/SolutionRestoreJob.cs#L384-L403

In our lab, for OrchardCore, we see the following (30 days worth of data):

| Step | Average Duration | Potential improvements |
| DgSpecDuration| 77ms | 0ms |
| UpToDateCheckDuration | 110ms | Unknown, equality overhead is likely smaller than the overhead of doing the disk check, so maybe not much |

In theory, the dg spec generation step could be improved significantly, but the up to date check step likely will retain most of it's overhead.

For a 56 project solution, the total overhead of both steps is ~40ms.

[erdembayar]

@nkolev92
As I tried to improve dg Spec evaluation, it's already quite fast for Netcore projects. So most likely this effort need to focus on up to date check part.

[nkolev92]

@erdembayar This issue suggests skipping both steps altogether.
The dg spec duration is fast, but it's still affected by the solution size, so linear, this proposal makes the overhead constant.