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
Conversation
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? |
0154855
to
f476247
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this 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?
57cf4f7
to
033ca1d
Compare
Shouldn't there be changes to |
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 |
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.
033ca1d
to
86db545
Compare
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.