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.

Sign up for GitHub

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

Jump to bottom

Merge LinkAssemblies and StripEmbeddedLibraries tasks #1092

Closed
radekdoulik opened this issue Dec 11, 2017 · 0 comments
Closed

Merge LinkAssemblies and StripEmbeddedLibraries tasks #1092

radekdoulik opened this issue Dec 11, 2017 · 0 comments
Assignees
@radekdoulik
Milestone
d15-9

Comments

@radekdoulik
Copy link
Member

An idea: it might be possible to improve build time by implementing striping the embedded libraries as linker step. We already load all the assemblies in the linker, so we might just strip them at the same time as well.

Expected Behavior

Strip embedded libraries in the linker. Possibly faster build times.

Actual Behavior

Stripping of embedded libraries is done as a separate target/task.
@radekdoulik radekdoulik self-assigned this Dec 11, 2017
@radekdoulik radekdoulik added this to the d15-7 milestone Dec 11, 2017
@jonpryor jonpryor modified the milestones: d15-7, d15-8 Mar 19, 2018
@jonpryor jonpryor modified the milestones: d15-8, d15-9 Apr 30, 2018
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Sep 7, 2018
@jonathanpeppers
[linker] move StripEmbeddedLibraries into the linker
de01200 
Fixes: dotnet#1092

The `StripEmbeddedLibraries` MSBuild task can take 1-2 seconds, and it
mainly removes `__AndroidLibraryProjects__.zip` from assemblies.

If we moved this to happen during linking, it has various benefits:
- The linker already has every assembly opened and loaded.
- We know if the linker is going to `Skip`/`Delete` an assembly, so we
  can likewise skip it.
- The linker writes all the assemblies out at the end, so we don't
  have a second "write" step.

Changes to make this happen:
- Removed the `StripEmbeddedLibraries` MSBuild task and related
  targets
- Removed `$(_AndroidStripFlag)` from our targets, since it is no
  longer used
- Created a new `StripEmbeddedLibraries` linker step that runs late
  during linking
- Removed a `RemoveLibraryResourceZip` linker step, as it seemed to be
  duplicative.

I timed before and after with the Xamarin.Forms test project:

    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Clean
    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Build /bl

Before:

     1233 ms  StripEmbeddedLibraries                     1 calls
    14925 ms  LinkAssemblies                             1 calls

After:

    15437 ms  LinkAssemblies                             1 calls

As expected, `LinkAssemblies` will be slightly slower. But since
`StripEmbeddedLibraries` is not called at all, we have a net gain of
around 700ms.

Once this has been merged and working for `Release` builds, I plan to
do some further research to find out if running the new
`StripEmbeddedLibraries` linker step will help for `Debug` builds. It
could be a net performance improvement, if the time taken to remove
these files improves deployment and app startup times.
@jonathanpeppers jonathanpeppers mentioned this issue Sep 7, 2018
Merged
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Sep 10, 2018
@jonathanpeppers
[linker] move StripEmbeddedLibraries into the linker
a547cb7 
Fixes: dotnet#1092

The `StripEmbeddedLibraries` MSBuild task can take 1-2 seconds, and it
mainly removes `__AndroidLibraryProjects__.zip` from assemblies.

If we moved this to happen during linking, it has various benefits:
- The linker already has every assembly opened and loaded.
- We know if the linker is going to `Skip`/`Delete` an assembly, so we
  can likewise skip it.
- The linker writes all the assemblies out at the end, so we don't
  have a second "write" step.

Changes to make this happen:
- Removed the `StripEmbeddedLibraries` MSBuild task and related
  targets
- Removed `$(_AndroidStripFlag)` from our targets, since it is no
  longer used
- Created a new `StripEmbeddedLibraries` linker step that runs late
  during linking
- Removed a `RemoveLibraryResourceZip` linker step, as it seemed to be
  duplicative.

I timed before and after with the Xamarin.Forms test project:

    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Clean
    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Build /bl

Before:

     1233 ms  StripEmbeddedLibraries                     1 calls
    14925 ms  LinkAssemblies                             1 calls

After:

    15437 ms  LinkAssemblies                             1 calls

As expected, `LinkAssemblies` will be slightly slower. But since
`StripEmbeddedLibraries` is not called at all, we have a net gain of
around 700ms.

Once this has been merged and working for `Release` builds, I plan to
do some further research to find out if running the new
`StripEmbeddedLibraries` linker step will help for `Debug` builds. It
could be a net performance improvement, if the time taken to remove
these files improves deployment and app startup times.

Greatly expanded upon an existing test:
- Made it a Xamarin.Forms project
- Moved the `AndroidEnvironment` item to a referenced library project
- Added an `$(AndroidLinkSkip)` option for a support library assembly
- Made sure the `$(AndroidLinkSkip)` assembly is saved and stripped
- Check and make sure `EmbeddedResource` items are stripped at the end

Other changes:
- Removed some assertions in tests looking for
  `_StripEmbeddedLibraries`, since it is removed now.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Sep 12, 2018
@jonathanpeppers
[linker] move StripEmbeddedLibraries into the linker
7ad753d 
Fixes: dotnet#1092

The `StripEmbeddedLibraries` MSBuild task can take 1-2 seconds, and it
mainly removes `__AndroidLibraryProjects__.zip` from assemblies.

If we moved this to happen during linking, it has various benefits:
- The linker already has every assembly opened and loaded.
- We know if the linker is going to `Skip`/`Delete` an assembly, so we
  can likewise skip it.
- The linker writes all the assemblies out at the end, so we don't
  have a second "write" step.

Changes to make this happen:
- Removed the `StripEmbeddedLibraries` MSBuild task and related
  targets
- Removed `$(_AndroidStripFlag)` from our targets, since it is no
  longer used
- Created a new `StripEmbeddedLibraries` linker step that runs late
  during linking
- Removed a `RemoveLibraryResourceZip` linker step, as it seemed to be
  duplicative.

I timed before and after with the Xamarin.Forms test project:

    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Clean
    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Build /bl

Before:

     1233 ms  StripEmbeddedLibraries                     1 calls
    14925 ms  LinkAssemblies                             1 calls

After:

    15437 ms  LinkAssemblies                             1 calls

As expected, `LinkAssemblies` will be slightly slower. But since
`StripEmbeddedLibraries` is not called at all, we have a net gain of
around 700ms.

Once this has been merged and working for `Release` builds, I plan to
do some further research to find out if running the new
`StripEmbeddedLibraries` linker step will help for `Debug` builds. It
could be a net performance improvement, if the time taken to remove
these files improves deployment and app startup times.

Greatly expanded upon an existing test:
- Made it a Xamarin.Forms project
- Moved the `AndroidEnvironment` item to a referenced library project
- Added an `$(AndroidLinkSkip)` option for a support library assembly
- Made sure the `$(AndroidLinkSkip)` assembly is saved and stripped
- Check and make sure `EmbeddedResource` items are stripped at the end

Other changes:
- Removed some assertions in tests looking for
  `_StripEmbeddedLibraries`, since it is removed now.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Sep 18, 2018
@jonathanpeppers
[linker] move StripEmbeddedLibraries into the linker
679cec9 
Fixes: dotnet#1092

The `StripEmbeddedLibraries` MSBuild task can take 1-2 seconds, and it
mainly removes `__AndroidLibraryProjects__.zip` from assemblies.

If we moved this to happen during linking, it has various benefits:
- The linker already has every assembly opened and loaded.
- We know if the linker is going to `Skip`/`Delete` an assembly, so we
  can likewise skip it.
- The linker writes all the assemblies out at the end, so we don't
  have a second "write" step.

Changes to make this happen:
- Removed the `StripEmbeddedLibraries` MSBuild task and related
  targets
- Removed `$(_AndroidStripFlag)` from our targets, since it is no
  longer used
- Created a new `StripEmbeddedLibraries` linker step that runs late
  during linking
- Removed a `RemoveLibraryResourceZip` linker step, as it seemed to be
  duplicative.

I timed before and after with the Xamarin.Forms test project:

    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Clean
    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Build /bl

Before:

     1233 ms  StripEmbeddedLibraries                     1 calls
    14925 ms  LinkAssemblies                             1 calls

After:

    15437 ms  LinkAssemblies                             1 calls

As expected, `LinkAssemblies` will be slightly slower. But since
`StripEmbeddedLibraries` is not called at all, we have a net gain of
around 700ms.

Once this has been merged and working for `Release` builds, I plan to
do some further research to find out if running the new
`StripEmbeddedLibraries` linker step will help for `Debug` builds. It
could be a net performance improvement, if the time taken to remove
these files improves deployment and app startup times.

Greatly expanded upon an existing test:
- Made it a Xamarin.Forms project
- Moved the `AndroidEnvironment` item to a referenced library project
- Added an `$(AndroidLinkSkip)` option for a support library assembly
- Made sure the `$(AndroidLinkSkip)` assembly is saved and stripped
- Check and make sure `EmbeddedResource` items are stripped at the end

Other changes:
- Removed some assertions in tests looking for
  `_StripEmbeddedLibraries`, since it is removed now.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Sep 20, 2018
@jonathanpeppers
[linker] move StripEmbeddedLibraries into the linker
ffa2819 
Fixes: dotnet#1092

The `StripEmbeddedLibraries` MSBuild task can take 1-2 seconds, and it
mainly removes `__AndroidLibraryProjects__.zip` from assemblies.

If we moved this to happen during linking, it has various benefits:
- The linker already has every assembly opened and loaded.
- We know if the linker is going to `Skip`/`Delete` an assembly, so we
  can likewise skip it.
- The linker writes all the assemblies out at the end, so we don't
  have a second "write" step.

Changes to make this happen:
- Removed the `StripEmbeddedLibraries` MSBuild task and related
  targets
- Removed `$(_AndroidStripFlag)` from our targets, since it is no
  longer used
- Created a new `StripEmbeddedLibraries` linker step that runs late
  during linking
- Removed a `RemoveLibraryResourceZip` linker step, as it seemed to be
  duplicative.

I timed before and after with the Xamarin.Forms test project:

    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Clean
    .\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Build /bl

Before:

     1233 ms  StripEmbeddedLibraries                     1 calls
    14925 ms  LinkAssemblies                             1 calls

After:

    15437 ms  LinkAssemblies                             1 calls

As expected, `LinkAssemblies` will be slightly slower. But since
`StripEmbeddedLibraries` is not called at all, we have a net gain of
around 700ms.

Once this has been merged and working for `Release` builds, I plan to
do some further research to find out if running the new
`StripEmbeddedLibraries` linker step will help for `Debug` builds. It
could be a net performance improvement, if the time taken to remove
these files improves deployment and app startup times.

Greatly expanded upon an existing test:
- Made it a Xamarin.Forms project
- Moved the `AndroidEnvironment` item to a referenced library project
- Added an `$(AndroidLinkSkip)` option for a support library assembly
- Made sure the `$(AndroidLinkSkip)` assembly is saved and stripped
- Check and make sure `EmbeddedResource` items are stripped at the end

Other changes:
- Removed some assertions in tests looking for
  `_StripEmbeddedLibraries`, since it is removed now.
jonpryor pushed a commit that referenced this issue Sep 21, 2018
@jonathanpeppers @jonpryor
[linker] move StripEmbeddedLibraries into the linker (#2162)
95aeb61 
Fixes: #1092

The `<StripEmbeddedLibraries/>` MSBuild task can take 1-2 seconds,
and it mainly removes `__AndroidLibraryProjects__.zip` from
assemblies.

If we moved this to happen during linking, it has various benefits:

  - The linker already has every assembly opened and loaded.
  - We know if the linker is going to `Skip`/`Delete` an assembly,
    so we can likewise skip it.
  - The linker writes all the assemblies out at the end, so we don't
    have a second "write" step.

Changes to make this happen:

  - Removed the `<StripEmbeddedLibraries/>` MSBuild task and related
    targets
  - Removed `$(_AndroidStripFlag)` from our targets, since it is no
    longer used
  - Created a new `StripEmbeddedLibraries` linker step that runs late
    during linking
  - Removed a `RemoveLibraryResourceZip` linker step, as it seemed to be
    duplicative.

I timed before and after with the Xamarin.Forms test project:

	.\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Clean
	.\bin\Debug\bin\xabuild .\tests\Xamarin.Forms-Performance-Integration\Droid\Xamarin.Forms.Performance.Integration.Droid.csproj /p:Configuration=Release /t:Build /bl

Before:

	 1233 ms  StripEmbeddedLibraries                     1 calls
	14925 ms  LinkAssemblies                             1 calls

After:

	15437 ms  LinkAssemblies                             1 calls

As expected, `<LinkAssemblies/>` will be slightly slower, but since
`<StripEmbeddedLibraries/>` is not called at all, we have a net gain
of around 700ms.

Once this has been merged and working for `Release` builds, I plan to
do some further research to find out if running the new
`StripEmbeddedLibraries` linker step will help for `Debug` builds.
It could be a net performance improvement, if the time taken to
remove these files improves deployment and app startup times.

Greatly expanded upon an existing test:

  - Made it a Xamarin.Forms project
  - Moved the `@(AndroidEnvironment)` item to a referenced library project
  - Added an `$(AndroidLinkSkip)` option for a support library assembly
  - Made sure the `$(AndroidLinkSkip)` assembly is saved and stripped
  - Check and make sure `@(EmbeddedResource)` items are stripped at the end

Other changes:

  - Removed some assertions in tests looking for
    `_StripEmbeddedLibraries`, since it is removed now.
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue May 13, 2020
@jonpryor
Bump to xamarin/monodroid@52312f24
cddac66 
Changes: xamarin/monodroid@cc88a89...52312f2

  * xamarin/monodroid@52312f241: Bump to xamarin/androidtools@d5b9818 (dotnet#1092)
  * xamarin/monodroid@0642b39a2: Bump to xamarin/xamarin-android/master@a01756 (dotnet#1087)
  * xamarin/monodroid@b892bc96b: [tools/RuntimeService] base versionCode off xamarin-android (dotnet#1088)
@jonpryor jonpryor mentioned this issue May 13, 2020
Merged
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue May 13, 2020
@jonpryor
Bump to xamarin/monodroid@e50ff9a4
2b7b2f4 
Changes: xamarin/monodroid@9242fa4...e50ff9a

  * xamarin/monodroid@e50ff9a43: Bump to xamarin/androidtools@ff35fa96 (dotnet#1092)
  * xamarin/monodroid@3d4f171a0: Bump to xamarin/xamarin-android/master@a01756 (dotnet#1087)
  * xamarin/monodroid@5560daf55: [tools/RuntimeService] base versionCode off xamarin-android (dotnet#1088)
@jonpryor jonpryor mentioned this issue May 13, 2020
Merged
jonpryor added a commit that referenced this issue May 14, 2020
@jonpryor
Bump to xamarin/monodroid@52312f24 (#4684)
2b9a019 
Changes: xamarin/monodroid@cc88a89...52312f2

  * xamarin/monodroid@52312f241: Bump to xamarin/androidtools@d5b9818 (#1092)
  * xamarin/monodroid@0642b39a2: Bump to xamarin/xamarin-android/master@a01756 (#1087)
  * xamarin/monodroid@b892bc96b: [tools/RuntimeService] base versionCode off xamarin-android (#1088)
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue May 14, 2020
@jonpryor
Bump to xamarin/monodroid@e50ff9a4
b455a86 
Changes: xamarin/monodroid@9242fa4...e50ff9a

  * xamarin/monodroid@e50ff9a43: Bump to xamarin/androidtools@ff35fa96 (dotnet#1092)
  * xamarin/monodroid@3d4f171a0: Bump to xamarin/xamarin-android/master@a01756 (dotnet#1087)
  * xamarin/monodroid@5560daf55: [tools/RuntimeService] base versionCode off xamarin-android (dotnet#1088)
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue May 14, 2020
@jonpryor
Bump to xamarin/monodroid@5849ea10
3eba2c3 
Changes: xamarin/monodroid@9242fa4...5849ea1

  * xamarin/monodroid@5849ea107 [tests] Fix build from xamarin-android (dotnet#1093)
  * xamarin/monodroid@e50ff9a43: Bump to xamarin/androidtools@ff35fa96 (dotnet#1092)
  * xamarin/monodroid@3d4f171a0: Bump to xamarin/xamarin-android/master@a01756 (dotnet#1087)
  * xamarin/monodroid@5560daf55: [tools/RuntimeService] base versionCode off xamarin-android (dotnet#1088)
jonpryor added a commit that referenced this issue May 14, 2020
@jonpryor
Bump to xamarin/monodroid@5849ea10 (#4685)
268c40d 
Changes: xamarin/monodroid@9242fa4...5849ea1

  * xamarin/monodroid@5849ea107 [tests] Fix build from xamarin-android (#1093)
  * xamarin/monodroid@e50ff9a43: Bump to xamarin/androidtools@ff35fa96 (#1092)
  * xamarin/monodroid@3d4f171a0: Bump to xamarin/xamarin-android/master@a01756 (#1087)
  * xamarin/monodroid@5560daf55: [tools/RuntimeService] base versionCode off xamarin-android (#1088)
@ghost ghost locked as resolved and limited conversation to collaborators Jun 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@radekdoulik radekdoulik

Labels
None yet
Projects
None yet
Milestone
d15-9
Development

No branches or pull requests
2 participants
@jonpryor @radekdoulik