For netcore vs netframework performance per phase, SDK structuring related differences is probably going to be a bag full of issues and probably a big chunk. But that is still a gap that needs to be bridged to get users moving to netcore with minimum friction. That will involve analyzing netcore hot patterns in msbuild evaluation and acquiring recommendations that can be passed onto the SDK teams or fixed inside msbuild and CPS.

1. Calling pattern change is implied by SDK requirements
2. Msbuild for .NETcore sdk codepath specific optimizations (Ex: SDK resolver)
3. CPS calling patterns that can be improved (Ex: shared evaluation across projects)
4. Calling pattern change is required and MSBuild should react by improving perf in a scenario that wasn’t hot before (Ex: globbing)

Note: I've already added some basic profiling to each pass stop to get a count of the items (properties, imports, item definitions, project item definitions, numberofUsingTaskElements, read targets) being processed. The ask is to look at the time delta and tell us which needs additional profiling to identify hot paths in netcore

Evaluation improvement suggestion from Daniel Plaisted

• For profiling from the commandline, use https://github.com/dotnet/msbuild/blob/master/documentation/evaluation-profiling.md. Given @ladipro's analysis, we could bypass the full solution load repro and use this profiling to analyze things better.
• An idea that Rainer had for improving evaluation time was to create a compiler for props and targets files which would translate them into executable .NET code. This would eliminate the overhead of parsing the XML, and then make evaluation faster by essentially changing it from being an interpreted to a compiled language. This could have a big impact on Visual Studio perf, as in a lot of scenarios they do re-evaluation (which can be slow on big projects), but don’t necessarily re-build.

Acceptance criteria:

• Re-measure on latest Dev17 build.
• For each evaluation pass understand why it takes longer for .NET Core than for .NET Framework projects.