You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
This was mostly here to improve diagnostic log output from XBuild,
which we no longer support.
MSBuild properly logs any input properties on MSBuild tasks, so we can
remove a lot of code!
There were a couple places I could go a step further:
<AndroidCreateDebugKey/> and <AndroidZipAlign/> I could remove
the entire Execute() method.
<JavaCompileToolTask/> had an OnLogStarted method I could
remove. <Javac/> also was overriding this method.
I thought this might have some impact on build times, since logging
and string.Format takes some time (it's not free!).
A build of the Xamarin.Forms app in this repo:
# Before
Time Elapsed 00:00:25.66
Time Elapsed 00:00:25.36
Time Elapsed 00:00:25.67
# After
Time Elapsed 00:00:24.58
Time Elapsed 00:00:23.98
Time Elapsed 00:00:24.98
The overall build times vary quite a bit. So if I took a conservative
estimate it seems the initial build is 500ms better?
A more revealing difference, I think, is the size of these binlog
files:
# fresh build
746947 before.first.binlog
740797 after.first.binlog
# build with no changes
827913 before.second.binlog
825665 after.second.binlog
# build with xaml change
848821 before.third.binlog
844365 after.third.binlog
These files are compressed, so if they are 2K-6K smaller that was a
lot of log messages...
We used to have the pattern of including log messages at the beginning
of `Execute()` in MSBuild tasks:
Log.LogDebugMessage ("MyMSBuildTask Task");
Log.LogDebugMessage (" FooProperty: {0}", FooProperty);
Log.LogDebugTaskItems (" BarItems: ", BarItems);
This was mostly here to improve diagnostic log output from XBuild,
which we no longer support.
MSBuild properly logs any input properties on MSBuild tasks, so we can
remove a lot of code!
There were a couple places I could go a step further:
* `<AndroidCreateDebugKey/>` and `<AndroidZipAlign/>` I could remove
the entire `Execute()` method.
* `<JavaCompileToolTask/>` had an `OnLogStarted` method I could
remove. `<Javac/>` also was overriding this method.
I thought this might have *some* impact on build times, since logging
and `string.Format` takes some time (it's not free!).
A build of the Xamarin.Forms app in this repo:
# Before
Time Elapsed 00:00:25.66
Time Elapsed 00:00:25.36
Time Elapsed 00:00:25.67
# After
Time Elapsed 00:00:24.58
Time Elapsed 00:00:23.98
Time Elapsed 00:00:24.98
The overall build times vary quite a bit. So if I took a conservative
estimate it seems the initial build is 500ms better?
A more revealing difference, I think, is the size of these binlog
files:
# fresh build
746947 before.first.binlog
740797 after.first.binlog
# build with no changes
827913 before.second.binlog
825665 after.second.binlog
# build with xaml change
848821 before.third.binlog
844365 after.third.binlog
These files are compressed, so if they are 2K-6K smaller that was a
lot of log messages...
Perusing the test failures, our network is bad and makes me feel bad (ALWAYS NETWORK FAILURES), Java.Interop-PerformanceTests.Possible Crash / Release is not that uncommon and is ignorable, but Mono.Android_TestsMultiDex.Possible Crash / Release is worrying:
XA/RuntimeTest: FAILURE: JNIEnv* wasn't changed!
This means that the condition the test was checking for isn't happening, which...could make some sense (that behavior was from a very old Android version, though the assertion has succeeded until now!), except we haven't touched the emulator or anything which would introduce such a change.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
3 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.
We used to have the pattern of including log messages at the beginning
of
Execute()
in MSBuild tasks:This was mostly here to improve diagnostic log output from XBuild,
which we no longer support.
MSBuild properly logs any input properties on MSBuild tasks, so we can
remove a lot of code!
There were a couple places I could go a step further:
<AndroidCreateDebugKey/>
and<AndroidZipAlign/>
I could removethe entire
Execute()
method.<JavaCompileToolTask/>
had anOnLogStarted
method I couldremove.
<Javac/>
also was overriding this method.I thought this might have some impact on build times, since logging
and
string.Format
takes some time (it's not free!).A build of the Xamarin.Forms app in this repo:
The overall build times vary quite a bit. So if I took a conservative
estimate it seems the initial build is 500ms better?
A more revealing difference, I think, is the size of these binlog
files:
These files are compressed, so if they are 2K-6K smaller that was a
lot of log messages...