[Xamarin.Android.Build.Tasks] cache java -version output #1938
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
Context: https://github.com/Microsoft/msbuild/blob/f147a76a60bf9e516800f65f9614c914df0a4f15/src/Framework/IBuildEngine4.cs#L34-L84 Context: https://github.com/xamarin/Xamarin.Forms/blob/42c07d1ae5aa56eb574b7d169499f1a9af7ec080/Xamarin.Forms.ControlGallery.Android/Xamarin.Forms.ControlGallery.Android.csproj The new `ValidateJavaVersion` MSBuild task gets invoked for *every* project on *every* build, regardless if there are changes or not. Unfortunately, this task also takes around 250ms to run, since it shells out to `java -version` and `javac -version`. We can use MSBuild's `GetRegisteredTaskObject` and `RegisterTaskObject` to cache the output of running these command line tools. If we key with the full path to `java` or `javac`, the cache should be properly invalidated if a different `JavaSdkPath` is passed in. I added a new set of `ValidateJavaVersionTests` to directly test this caching functionality, plus a couple smoke tests. In the case of `Xamarin.Forms.ControlGallery.Android`: - `ValidateJavaVersion` runs 7 times - A build (with no changes) went from 12.820s to 11.185s, saving ~1.635s of build time - I also tested the changes in VS Windows, and was able to see logs indicating the value is cached. Improvements to `MockBuildEngine`: - General code formatting / refactoring - Added a `Messages` list that can be asserted against - Refactored the `Task` APIs so that they are fully functional Other changes: - Since `BaseTest` now has a `SetUp` class, we can't have a method named `SetUp` or we get a warning. I used a `Setup` method (with lowercase u) instead, and modified `KeyToolTests` to fix this warning.
|
Let's wait and make sure #1916 is good (bumped in monodroid) before we merge this one. |
dellis1972
approved these changes
Jul 9, 2018
|
#1916 is now in monodroid/master, things seem to be OK. |
jonpryor
pushed a commit
that referenced
this pull request
Aug 3, 2018
Context: https://github.com/Microsoft/msbuild/blob/f147a76a60bf9e516800f65f9614c914df0a4f15/src/Framework/IBuildEngine4.cs#L34-L84 Context: https://github.com/xamarin/Xamarin.Forms/blob/42c07d1ae5aa56eb574b7d169499f1a9af7ec080/Xamarin.Forms.ControlGallery.Android/Xamarin.Forms.ControlGallery.Android.csproj The new `<ValidateJavaVersion/>` MSBuild task (93ddf96) gets invoked for *every* project on *every* build, even if nothing changed. Unfortunately, this task also takes around 250ms to run, since it shells out to `java -version` and `javac -version`. We can use MSBuild's `GetRegisteredTaskObject()` and `RegisterTaskObject()` to cache the output of running these command line tools. If we key with the full path to `java` or `javac`, the cache should be properly invalidated if a different `$(JavaSdkDirectory)` value is passed in. I added a new set of `ValidateJavaVersionTests` to directly test this caching functionality, plus a couple smoke tests. In the case of `Xamarin.Forms.ControlGallery.Android`: - `<ValidateJavaVersion/>` runs 7 times - A build (with no changes) went from 12.820s to 11.185s, saving ~1.635s of build time - I also tested the changes in VS Windows, and was able to see logs indicating the value is cached. Improvements to `MockBuildEngine`: - General code formatting / refactoring - Added a `Messages` list that can be asserted against - Refactored the `Task` APIs so that they are fully functional Other changes: - Since `BaseTest` now has a `SetUp` class, we can't have a method named `SetUp` or we get a warning. I used a `Setup` method (with lowercase u) instead, and modified `KeyToolTests` to fix this warning.
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.
Context: https://github.com/Microsoft/msbuild/blob/f147a76a60bf9e516800f65f9614c914df0a4f15/src/Framework/IBuildEngine4.cs#L34-L84
Context: https://github.com/xamarin/Xamarin.Forms/blob/42c07d1ae5aa56eb574b7d169499f1a9af7ec080/Xamarin.Forms.ControlGallery.Android/Xamarin.Forms.ControlGallery.Android.csproj
The new
ValidateJavaVersionMSBuild task gets invoked for everyproject on every build, regardless if there are changes or not.
Unfortunately, this task also takes around 250ms to run, since it
shells out to
java -versionandjavac -version.We can use MSBuild's
GetRegisteredTaskObjectandRegisterTaskObjectto cache the output of running these command linetools. If we key with the full path to
javaorjavac, the cacheshould be properly invalidated if a different
JavaSdkPathis passedin. I added a new set of
ValidateJavaVersionTeststo directly testthis caching functionality, plus a couple smoke tests.
In the case of
Xamarin.Forms.ControlGallery.Android:ValidateJavaVersionruns 7 times~1.635s of build time
indicating the value is cached.
Improvements to
MockBuildEngine:Messageslist that can be asserted againstTaskAPIs so that they are fully functionalOther changes:
BaseTestnow has aSetUpclass, we can't have a methodnamed
SetUpor we get a warning. I used aSetupmethod (withlowercase u) instead, and modified
KeyToolTeststo fix thiswarning.