General performance plan one pager

[MichalPavlik]

One pager for the next iteration.

[JanKrivanek]

Great!

[baronfel]

Thanks for getting this started. I have a few notes/comments that didn't really make sense in-line anywhere that I could find.

MSBuild Usages

I'd like to see a section outlining the different 'customers' (hosts/users) of MSBuild to help inform the discussion of the impact for each use case. For example, the list might be:

• VS driving builds via APIs (but not the orchestration side of MSBuild) and doing project evaluations
• DevKit/Ionide/Draco lang/other VSCode extensions doing evaluations in-memory and driving builds via the CLI
• Some SDK commands doing evaluations in-memory and builds via the API
• The Build/Pack/Publish/Clean/etc commands all doing builds via the CLI (and sometimes doing evaluations in-memory immediately before that)
• CLI based users doing evaluations using the -getProperty/-getItem/-getTargetResults flags

Each of these use cases will have different needs, and a particular solution might help some and not others based on that usage. For example, the MSBuild CLI caching project evaluations wouldn't help VS, Dev Kit, Ionide in-memory evaluations necessarily, but could help all CLI usage, which would partially accrue to Dev Kit/Ionide usage and all CI/CD and user-CLI usage.

Preventing regressions

This is something that adds to the cost of the implementation, but once a perf fix is identified we should invest in guardrails, ideally as 'close' to the MSBuild repo as possible, to prevent regressing that fix. While some scenarios are hard to detect without a full VS insertion, our goal should be to have a mix of unit/integration/benchmarks/perfstar tests that keep validation 'closer' to the dev cycle of MSBuild to give us the best possible response time.

[rainersigwald]

I'd like to see a section outlining the different 'customers' (hosts/users) of MSBuild to help inform the discussion of the impact for each use case. For example, the list might be:

• VS driving builds via APIs (but not the orchestration side of MSBuild) and doing project evaluations
• DevKit/Ionide/Draco lang/other VSCode extensions doing evaluations in-memory and driving builds via the CLI
• Some SDK commands doing evaluations in-memory and builds via the API
• The Build/Pack/Publish/Clean/etc commands all doing builds via the CLI (and sometimes doing evaluations in-memory immediately before that)
• CLI based users doing evaluations using the -getProperty/-getItem/-getTargetResults flags

cough #11002