Optimize the case when we have a generator not producing output#52979
Merged
jasonmalinowski merged 1 commit intodotnet:release/dev16.10from Apr 29, 2021
Merged
Conversation
In 63a1ad6 we made some performance optimizations where we would try to reuse compilations better. The core idea was if a change to a file happens, we have to update the compilation that doesn't contain source generated files so we can re-run generators; if the generated output was the same then we should also do the same updates to the compilation that _has_ source generators so we can better use compiler caches. The one case that wasn't handled well was if the compilation with and without generated output was actually the same: if a generator was added that isn't producing documents, then those compilations can be the same instance, but we were applying the transformations twice as if they were different. This fired an assert elsewhere in the CompilationTracker that when we're storing compilations away at the very end we shouldn't have two separate but semantically identical compilations if there are no actual generated files anywhere. The fix taken here is to adjust our logic where we update compilations for changes to regular files: there we were updating both compilations at once. If the compilations are identical, we just null out the "withGenerators" since we won't need to update that as well. That way we're only updating one copy, which will be the one passed to generators again. And if no generated output is still produced, that'll be the single compilation again stored in the FinalState.
70f3e62 to
d3801b3
Compare
JoeRobich
approved these changes
Apr 28, 2021
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In 63a1ad6 we made some performance optimizations where we would try to reuse compilations better. The core idea was if a change to a file happens, we have to update the compilation that doesn't contain source generated files so we can re-run generators; if the generated output was the same then we should also do the same updates to the compilation that has source generators so we can better use compiler caches.
The one case that wasn't handled well was if the compilation with and without generated output was actually the same: if a generator was added that isn't producing documents, then those compilations can be the same instance, but we were applying the transformations twice as if they were different. This fired an assert elsewhere in the CompilationTracker that when we're storing compilations away at the very end we shouldn't have two separate but semantically identical compilations if there are no actual generated files anywhere.
The fix taken here is to adjust our logic where we update compilations for changes to regular files: there we were updating both compilations at once. If the compilations are identical, we just null out the "withGenerators" since we won't need to update that as well. That way we're only updating one copy, which will be the one passed to generators again. And if no generated output is still produced, that'll be the single compilation again stored in the FinalState.