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

Don't package empty AOT-d DSOs #6477

Merged
merged 4 commits into from Nov 22, 2021
Merged

Conversation

grendello
Copy link
Member

@grendello grendello commented Nov 10, 2021

Fixes: #3932

Profiled AOT tends to produce a number of "empty" .so shared libraries
because the profile names only a handful of types from a handful of
assemblies and the AOT compiler in Mono currently doesn't support not
outputting the .so in such cases.

This has the unfortunate effect that an application may have a large
number of such empty .so libraries and each of them will have to be
opened and loaded before Mono can determine that there's no code in them
and the JIT has to compile the requested types and methods. Loading
every .so takes a non-zero amount of time, especially if the shared
libraries aren't unpacked to the filesystem. I've seen times between 10
and 30ms to load a single shared library, which can add up to a
non-trivial amount of time wasted loading empty libraries.

This commit adds code to examine and ignore such .so files which don't
include any executable code. The checks are crafted so that only AOT-d
libraries are considered for rejection.

Time savings are around 3ms for a plain XA app and around 10ms for a
sample MAUI app on the Pixel 3 XL phone. In the latter case 49 shared
libraries out of 120 total are rejected and not packaged, contributing
to (small, each empty DSO is between 7 and 25k) space savings in the APK
in addition to slightly better startup performance.

@grendello grendello marked this pull request as ready for review November 10, 2021 20:07
@dellis1972
Copy link
Contributor

I'm wondering, do we put any Metadata on the AOT'd libraries which we could use to early out this whole process. It would allow us to completely skip the .so file which don't have the required metadata.

@grendello
Copy link
Member Author

I'm wondering, do we put any Metadata on the AOT'd libraries which we could use to early out this whole process. It would allow us to completely skip the .so file which don't have the required metadata.

This would move the check to earlier than BuildApk, perhaps it would be a better idea to check after we AOT the so and add the Metadata?

@grendello
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@jonathanpeppers jonathanpeppers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this PR close this one, too?

#3932

@grendello grendello force-pushed the profiled-aot-less-dsos branch 2 times, most recently from 57cf4f7 to 033ca1d Compare November 15, 2021 16:52
@jonpryor
Copy link
Member

Shouldn't there be changes to tests/apk-sizes-reference/Xamarin.Forms_Performance_Integration-Signed-Release-Profiled-Aot.apkdesc? Seems hard to believe that e.g. libaot-Plugin.Connectivity.Abstractions.dll.so has any code in there, or libaot-Xamarin.AndroidX.Lifecycle.Common.dll.so, or…

@grendello
Copy link
Member Author

Shouldn't there be changes to tests/apk-sizes-reference/Xamarin.Forms_Performance_Integration-Signed-Release-Profiled-Aot.apkdesc? Seems hard to believe that e.g. libaot-Plugin.Connectivity.Abstractions.dll.so has any code in there, or libaot-Xamarin.AndroidX.Lifecycle.Common.dll.so, or…

The assemblies are AOT-d according to a pre-cooked profile, and also the code that filters them is very conservative since it's better to let something through the crack than to not package a .so that's needed.

Fixes: xamarin#3932

Profiled AOT tends to produce a number of "empty" .so shared libraries
because the profile names only a handful of types from a handful of
assemblies and the AOT compiler in Mono currently doesn't support not
outputting the .so in such cases.

This has the unfortunate effect that an application may have a large
number of such empty .so libraries and each of them will have to be
opened and loaded before Mono can determine that there's no code in them
and the JIT has to compile the requested types and methods.  Loading
every .so takes a non-zero amount of time, especially if the shared
libraries aren't unpacked to the filesystem.  I've seen times between 10
and 30ms to load a single shared library, which can add up to a
non-trivial amount of time wasted loading empty libraries.

This commit adds code to examine and ignore such .so files which don't
include any executable code.  The checks are crafted so that only AOT-d
libraries are considered for rejection.

Time savings are around 3ms for a plain XA app and around 10ms for a
sample MAUI app on the Pixel 3 XL phone.  In the latter case 49 shared
libraries out of 120 total are rejected and not packaged, contributing
to (small, each empty DSO is between 7 and 25k) space savings in the APK
in addition to slightly better startup performance.
@jonpryor jonpryor merged commit db161ae into xamarin:main Nov 22, 2021
@grendello grendello deleted the profiled-aot-less-dsos branch November 22, 2021 16:25
@github-actions github-actions bot locked and limited conversation to collaborators Jan 24, 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.

Do not add AOT'ed assemblies with 0 methods added
4 participants