_ComputeLockFileReferences/RunResolvePackageDependencies should be faster when projects are up-to-date

[davkean]

Investigating up-to-date builds from ASP.NET, I've found that _ComputeLockFileReferences/RunResolvePackageDependencies is taking a non-trivial amount of time (> 17%) of the build time when a project is considered up-to-date.

109>        1 ms  CheckForImplicitPackageReferenceOverrides   1 calls
109>        1 ms  IncludeTransitiveProjectReferences         1 calls
109>        1 ms  ExpandSDKReferences                        1 calls
109>        1 ms  CoreCompile                                1 calls
109>        2 ms  GenerateBuildRuntimeConfigurationFiles     1 calls
109>        3 ms  _ComputeActiveTFMFileDependencies          1 calls
109>        3 ms  CopyFilesToOutputDirectory                 1 calls
109>        4 ms  ResolveLockFileReferences                  1 calls
109>        7 ms  _ComputeActiveTFMPackageDependencies       1 calls
109>       10 ms  _ComputeTFMOnlyFileDependencies            1 calls
109>       15 ms  GetTargetFrameworkProperties              79 calls
109>       19 ms  _GenerateCompileDependencyCache            1 calls
109>       20 ms  _CopyFilesMarkedCopyLocal                  1 calls
109>       25 ms  _ComputeTransitiveProjectReferences        1 calls
109>       27 ms  AssignProjectConfiguration                 1 calls
109>       27 ms  IncrementalClean                           1 calls
109>       32 ms  _SplitProjectReferencesByFileExistence     1 calls
109>       49 ms  GetCopyToOutputDirectoryItems              1 calls
109>      122 ms  _CleanGetCurrentAndPriorFileWrites         1 calls
109>      141 ms  ResolveProjectReferences                   1 calls
109>      368 ms  RunResolvePackageDependencies              1 calls <-- This bug
109>      912 ms  _ComputeLockFileReferences                 1 calls <-- This bug
109>     1630 ms  ResolveAssemblyReferences                  1 calls
109>     5970 ms  _GetProjectReferenceTargetFrameworkProperties  95 calls

We should investigate ways of caching/making this faster.

[jeromelaban]

This issue is pretty visible in visual studio, where a non-modified project should not be touched. Large solutions get pretty long to build if everything is cross-targeted.

[mikeharder]

@nguerrera: Is this resolved by #1857?

[nguerrera]

There is still more we can do, but #1857 should make this dramatically better.

[nguerrera]

I'm going to go ahead and close this as fixed by #1857. It will be best to reopen a more specific bug for any refinements beyond that should the new task/target still be a place to focus.