[Xamarin.Android.Build.Tasks] _CopyIntermediateAssemblies uses CopyIfChanged#2128
Merged
dellis1972 merged 1 commit intoSep 3, 2018
Merged
Conversation
…Changed Context: dotnet#2088 970da9e was a good step towards "correctness" in building incrementally in the following scenario: - File | New Xamarin.Forms project | NetStandard library - Build - Change XAML - Build In this scenario, there is now a new target rising to the surface we can improve: 276 ms _CopyIntermediateAssemblies 1 calls Looking at the target, it seems we could use the `CopyIfChanged` task here more effectively. This task will automaticaly set the timestamps of files that have been copied, and so we don't need any subsequent `<ItemGroup />` or `<Touch />` elements. It was also touching *all* files instead of just the ones that were changed. After this change: 33 ms _CopyIntermediateAssemblies 1 calls The overall build went from 7.058s to 6.652s, so there must be some other targets that benefit from the timestamps not changing on *all* of these files.
Member
Author
|
Build logs here: CopyIntermediateAssemblies.zip |
dellis1972
approved these changes
Sep 3, 2018
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this pull request
Oct 16, 2018
Context: dotnet#2247 Context: dotnet#2128 The `_CopyIntermediateAssemblies` target has a bug for incremental builds, reproduced by the following: - Build a Xamarin.Android app project - `touch` the project's assembly in `$(IntermediateOutputPath)` - Build a second time. `_CopyIntermediateAssemblies` will run as expected. - Build a third time. `_CopyIntermediateAssemblies` will still run! When in this state, `_CopyIntermediateAssemblies` will always run. This is bad because it triggers other expensive targets like `_UpdateAndroidResgen` _every time_. I believe I introduced this in dotnet#2128, which was when I saw `_CopyIntermediateAssemblies` taking more time than it used to. It was a good tradeoff though, since it prevented `_UpdateAndroidResgen` from running too often. 15.9 does not have dotnet#2128. To fix this problem properly, I introduced a new `_copyintermediate.stamp` file to be used as the `Outputs` of the target. In addition to fixing our incremental build here, there should be performance gains in only verifying the timestamp of one file in `Outputs`. The `Inputs` of the `_CopyIntermediateAssemblies` were also incorrect, as it was not using the "satellite" assembly files as an input. This does not fully complete dotnet#2247, as there are two other targets listed I need to investigate further. These are likely unrelated to the changes in dotnet#2128.
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
Context: #2088
970da9e was a good step towards "correctness" in building
incrementally in the following scenario:
In this scenario, there is now a new target rising to the surface we
can improve:
Looking at the target, it seems we could use the
CopyIfChangedtaskhere more effectively. This task will automaticaly set the timestamps
of files that have been copied, and so we don't need any subsequent
<ItemGroup />or<Touch />elements. It was also touching allfiles instead of just the ones that were changed.
After this change:
The overall build went from 7.058s to 6.652s, so there must be some
other targets that benefit from the timestamps not changing on all
of these files.