Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Xamarin.Android.Build.Tasks] more ConvertResourcesCases improvements #2328

Merged

Conversation

jonathanpeppers
Copy link
Member

Context: http://www.getcodetrack.com/

I used a "freeware" .NET profiler to see what it would turn up.

Using the tool, I profiled the following .NET process:

.\bin\Debug\bin\xabuild.exe .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /v:quiet

This seemed to have a lot of useful information, and I quickly noticed:

Monodroid.AndroidResource.UpdateXmlResource -> 3683 calls -> 2.13s
..
    Monodroid.AndroidResource.ResourceNeedsToBeLowerCased -> 2384 calls - 319.53ms

This is a known codepath, the ConvertResourcesCases MSBuild task,
that we know takes a bit of time.

Looking through the call stack, I saw two points we could make easy
fixes for:

  • A Regex in AndroidResource was not using RegexOptions.Compiled
  • There was a string append dirPrefix + "*" in a LINQ expression
    that could be done up front.
  • There was a bit of LINQ usage such as:
if (Directory.EnumerateDirectories (resourceBasePath, dirPrefix + "*").Any (dir => Directory.EnumerateFiles (dir, fileNamePattern).Any ()))

So I added RegexOptions.Compiled and converted the LINQ expressions
to foreach loops. I could see a noticeable change in these methods
which moved further down the list of methods, when sorted by time
duration.

But since the time differences in the profiler likely aren't going
to reflect the real world, I did a before/after comparision with the
Xamarin.Forms.ControlGallery project.

Project here:
https://github.com/jonathanpeppers/Xamarin.Forms/tree/msbuild-timing/Xamarin.Forms.ControlGallery.Android
Script here:
https://github.com/jonathanpeppers/msbuild-timing/blob/master/xamarin.forms.ps1

Before:

7224 ms  ConvertResourcesCases                      6 calls

After:

7034 ms  ConvertResourcesCases                      6 calls

So about a 200ms improvement on Windows, for adjusting a bit of code.

I suspect the improvement won't be as good on MacOS, since I don't
believe RegexOptions.Compiled is implemented in Mono. (It is safely
ignored)

Other changes:

  • Code such as (value ?? String.Empty).Trim ();
  • Simplified to value?.Trim ();
  • Removed unused filePath variable

Future changes:

It may be worth auditing all regexes and adding
RegexOptions.Compiled if they appear to be called a lot?

Context: http://www.getcodetrack.com/

I used a "freeware" .NET profiler to see what it would turn up.

Using the tool, I profiled the following .NET process:

    .\bin\Debug\bin\xabuild.exe .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /v:quiet

This seemed to have a lot of useful information, and I quickly noticed:

    Monodroid.AndroidResource.UpdateXmlResource -> 3683 calls -> 2.13s
    ..
        Monodroid.AndroidResource.ResourceNeedsToBeLowerCased -> 2384 calls - 319.53ms

This is a known codepath, the `ConvertResourcesCases` MSBuild task,
that we know takes a bit of time.

Looking through the call stack, I saw two points we could make easy
fixes for:
- A `Regex` in `AndroidResource` was not using `RegexOptions.Compiled`
- There was a string append `dirPrefix + "*"` in a LINQ expression
  that could be done up front.
- There was a bit of LINQ usage such as:

    if (Directory.EnumerateDirectories (resourceBasePath, dirPrefix + "*").Any (dir => Directory.EnumerateFiles (dir, fileNamePattern).Any ()))

So I added `RegexOptions.Compiled` and converted the LINQ expressions
to `foreach` loops. I could see a noticeable change in these methods
which moved further down the list of methods, when sorted by time
duration.

But since the time differences *in the profiler* likely aren't going
to reflect the real world, I did a before/after comparision with the
Xamarin.Forms.ControlGallery project.

Project here:
https://github.com/jonathanpeppers/Xamarin.Forms/tree/msbuild-timing/Xamarin.Forms.ControlGallery.Android
Script here:
https://github.com/jonathanpeppers/msbuild-timing/blob/master/xamarin.forms.ps1

Before:

    7224 ms  ConvertResourcesCases                      6 calls

After:

    7034 ms  ConvertResourcesCases                      6 calls

So about a 200ms improvement on Windows, for adjusting a bit of code.

I suspect the improvement won't be as good on MacOS, since I don't
believe `RegexOptions.Compiled` is implemented in Mono. (It is safely
ignored)

Other changes:

- Code such as `(value ?? String.Empty).Trim ();`
- Simplified to `value?.Trim ();`
- Removed unused `filePath` variable

Future changes:

It may be worth auditing all regexes and adding
`RegexOptions.Compiled` if they appear to be called a lot?
@jonathanpeppers
Copy link
Member Author

Build logs: logs.zip

@dellis1972 dellis1972 merged commit f7769ef into dotnet:master Oct 23, 2018
@jonathanpeppers jonathanpeppers deleted the convertresourcescases-linq branch October 25, 2018 13:46
@github-actions github-actions bot locked and limited conversation to collaborators Feb 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants