Repository navigation
Add Precompute Mode Overview Doc - #15238
benwitmanmsft wants to merge 1 commit into
Conversation
| By default each target (specifically each batch of a target) becomes a separate node in the build graph with input/output files defined by the target. | ||
| Targets can also be merged together into a single node to optimize the build graph. | ||
| Additionally, there are also more explicit ways to declare inputs and outputs beyond the default file-based attributes on targets. | ||
| All inputs and outputs must be completely declared. |
There was a problem hiding this comment.
I am thinking we remove "All inputs and outputs must be completely declared." because of two-phase lookup and we already have the next sentence "If a target attempts to read or write undeclared data during execution it fails."
There was a problem hiding this comment.
To me these are two different facts that are somewhat important to both note, I kind of agree the second implies the first, but I think it's unfortunately important to note that this is a new requirement - Copilot especially was pointing out that MSBuild SDK authors often purposefully omit inputs/outputs and so this is an important departure from that.
There was a problem hiding this comment.
Fair enough - is there a way to express "you need to define inputs, but you don't need to individually express every single input"
| Precompute mode separates the creation of a build graph, called the precompute phase, from the execution of that build graph, called the compute phase, and uses that foundation to improve the reliability and performance of the build. | ||
|
|
||
| This document is meant to be an introduction to precompute mode while the full specification and detailed design are still under development and will be provided in future updates. | ||
|
|
There was a problem hiding this comment.
Goals
MSBuild is not on-par with the performance or correctness of other modern build systems (e.g. BuildXL, Bazel). Precompute aims to close this gap.
There was a problem hiding this comment.
let's see what the MSBuild folks say - I don't want to put this kind of subjective/opinion-based in here as I don't want the discussion/content to be focused on whether "on-par" is accurate or not. MSBuild can be way faster than BuildXL and Bazel today so I think even this statement doesn't capture that nuance.
There was a problem hiding this comment.
Sounds good - I'd like to somehow indicate that this is a big step function - this isn't a 5% improvement.
There was a problem hiding this comment.
I agree with that sentiment - we should find some way to explain this is a big change and it has big implications for perf/correctness.
I do have a more detailed explanation of each case that is a reliability or performance issue and here is how current MSBuild handles it and how precompute does which would be a good way to really illustrate it, but that's a big change.
This branch has not been deployed
2 participants
Adds preliminary documentation about precompute mode to the proposed specs. This is not exhaustive and more documentation should be added later to continue to clarify precompute mode, but this serves as a basic introduction.