[Xamarin.Android.Build.Tasks] precompile SetVsMonoAndroidRegistryKey #2130
Conversation
This file contains 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
In `Xamarin.Android.Sdk.props` we have some inline C# code for a
MSBuild task named `SetVsMonoAndroidRegistryKey`. Which is
understandable, since the code needed is so simple. But thinking about
it, MSBuild has to *compile* this code to run it. Which seems
inherently slower than if we compiled the code during our build.
Currently its entire parent target, `RedirectMonoAndroidSdkPaths`,
takes:
157 ms RedirectMonoAndroidSdkPaths 1 calls
I moved this task inside `Xamarin.Android.Build.Tasks.dll`, and we
appear to get some improvements "for free":
76 ms RedirectMonoAndroidSdkPaths 1 calls
I looked at some past logs, and there are some times where the
`RedirectMonoAndroidSdkPaths` target was taking over 200ms. I suspect
MSBuild might also have some caching functionality for inlined C#
code. There might be a cached assembly somewhere? Not sure.
What makes this a better fix is that this target runs for all
builds--even builds with no changes.
General changes:
- The `<UsingTask />` doesn't need a condition, since it will be
lazily evaluated anyways.
- Used string interpolation where it looked nicer.
- Used `LogDebugMessage` and improved the log message.
|
Logs for this: RedirectMonoAndroidSdkPaths.zip |
|
I think the build failure is unrelated, this target doesn't run at all on Mac? The error is: |
jonpryor
pushed a commit
that referenced
this pull request
Sep 5, 2018
…2130) In `Xamarin.Android.Sdk.props` we have some inline C# code for a MSBuild task named `SetVsMonoAndroidRegistryKey`. Which is understandable, since the code needed is so simple. But thinking about it, MSBuild has to *compile* this code to run it. Which seems inherently slower than if we compiled the code during our build. Currently its entire parent target, `RedirectMonoAndroidSdkPaths`, takes: 157 ms RedirectMonoAndroidSdkPaths 1 calls I moved this task inside `Xamarin.Android.Build.Tasks.dll`, and we appear to get some improvements "for free": 76 ms RedirectMonoAndroidSdkPaths 1 calls I looked at some past logs, and there are some times where the `RedirectMonoAndroidSdkPaths` target was taking over 200ms. I suspect MSBuild might also have some caching functionality for inlined C# code. There might be a cached assembly somewhere? Not sure. What makes this a better fix is that this target runs for all builds--even builds with no changes. General changes: - The `<UsingTask/>` doesn't need a condition, since it will be lazily evaluated anyways. - Used string interpolation where it looked nicer. - Used `LogDebugMessage()` and improved the log message.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
Xamarin.Android.Sdk.propswe have some inline C# code for aMSBuild task named
SetVsMonoAndroidRegistryKey. Which isunderstandable, since the code needed is so simple. But thinking about
it, MSBuild has to compile this code to run it. Which seems
inherently slower than if we compiled the code during our build.
Currently its entire parent target,
RedirectMonoAndroidSdkPaths,takes:
I moved this task inside
Xamarin.Android.Build.Tasks.dll, and weappear to get some improvements "for free":
I looked at some past logs, and there are some times where the
RedirectMonoAndroidSdkPathstarget was taking over 200ms. I suspectMSBuild might also have some caching functionality for inlined C#
code. There might be a cached assembly somewhere? Not sure.
What makes this a better fix is that this target runs for all
builds--even builds with no changes.
General changes:
<UsingTask />doesn't need a condition, since it will belazily evaluated anyways.
LogDebugMessageand improved the log message.