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] perf improvements for <ResolveAssemblies/> #4236

Merged

Conversation

jonathanpeppers
Copy link
Member

When building the SmartHotel360 app, I found that
<ResolveAssemblies/> was loading the NuGet ProjectAssetFile /
LockFile even though it was not used by the task at all. Putting a
Stopwatch around the code, I also found it to be somewhat expensive.

I reworked the code to use a Lazy<T> for accessing the LockFile.
This way it is not actually loaded until it is needed.

I also found several LogDebugMessage calls that seemed to be too
much... The <ResolveAssemblies/> was emitting hundreds of lines of
logging in the SmartHotel360 app.

I removed two messages such as:

LogDebugMessage ($"Adding {resolved_assembly} to topAssemblyReferences");
...
LogDebugMessage ("{0}={1}", assemblyName, apiLevel);

The [Input] and [Output] values for the task and the remaining log
message should be sufficient for understanding what we need from
customer logs:

LogMessage ("{0}Adding assembly reference for {1}, recursively...", new string (' ', indent), assemblyName);

The results for a build with no changes with the SmartHotel360 app:

Before:
320 ms  ResolveAssemblies                          1 calls
After:
238 ms  ResolveAssemblies                          1 calls

This saves ~82ms, and since this task runs on every Build and
Install, it could save ~164ms from the dev-loop.

When building the SmartHotel360 app, I found that
`<ResolveAssemblies/>` was loading the NuGet `ProjectAssetFile` /
`LockFile` even though it was not used by the task at all. Putting a
`Stopwatch` around the code, I also found it to be somewhat expensive.

I reworked the code to use a `Lazy<T>` for accessing the `LockFile`.
This way it is not actually loaded until it is needed.

I also found several `LogDebugMessage` calls that seemed to be too
much... The `<ResolveAssemblies/>` was emitting hundreds of lines of
logging in the SmartHotel360 app.

I removed two messages such as:

    LogDebugMessage ($"Adding {resolved_assembly} to topAssemblyReferences");
    ...
    LogDebugMessage ("{0}={1}", assemblyName, apiLevel);

The `[Input]` and `[Output]` values for the task and the remaining log
message should be sufficient for understanding what we need from
customer logs:

    LogMessage ("{0}Adding assembly reference for {1}, recursively...", new string (' ', indent), assemblyName);

The results for a build with no changes with the SmartHotel360 app:

    Before:
    320 ms  ResolveAssemblies                          1 calls
    After:
    238 ms  ResolveAssemblies                          1 calls

This saves ~82ms, and since this task runs on every `Build` and
`Install`, it could save ~164ms from the dev-loop.
@jonathanpeppers
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jonathanpeppers
Copy link
Member Author

The build failures look to be on master, too: apk sizes, tls tests, designer, libZipSharp/DotNetPackageXASdkProject test.

@jonathanpeppers jonathanpeppers merged commit 97d250b into dotnet:master Feb 10, 2020
@jonathanpeppers jonathanpeppers deleted the resolveassemblies-lockfile branch February 10, 2020 16:29
jonpryor pushed a commit that referenced this pull request Feb 11, 2020
…s/> (#4236)

When building the SmartHotel360 app, I found that
`<ResolveAssemblies/>` was loading the NuGet `ProjectAssetFile` /
`LockFile` even though it was not used by the task at all. Putting a
`Stopwatch` around the code, I also found it to be somewhat expensive.

I reworked the code to use a `Lazy<T>` for accessing the `LockFile`.
This way it is not actually loaded until it is needed.

I also found several `LogDebugMessage` calls that seemed to be too
much... The `<ResolveAssemblies/>` was emitting hundreds of lines of
logging in the SmartHotel360 app.

I removed two messages such as:

    LogDebugMessage ($"Adding {resolved_assembly} to topAssemblyReferences");
    ...
    LogDebugMessage ("{0}={1}", assemblyName, apiLevel);

The `[Input]` and `[Output]` values for the task and the remaining log
message should be sufficient for understanding what we need from
customer logs:

    LogMessage ("{0}Adding assembly reference for {1}, recursively...", new string (' ', indent), assemblyName);

The results for a build with no changes with the SmartHotel360 app:

    Before:
    320 ms  ResolveAssemblies                          1 calls
    After:
    238 ms  ResolveAssemblies                          1 calls

This saves ~82ms, and since this task runs on every `Build` and
`Install`, it could save ~164ms from the dev-loop.
@github-actions github-actions bot locked and limited conversation to collaborators Jan 28, 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.

3 participants