forked from dotnet/android
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[monodroid] Pre-allocate buffers for embedded assembly names (dotnet#…
…6188) When Embedded Assemblies are used (`$(EmbedAssembliesIntoApk)`=True), assembly names are detected during `.apk` content traversal, duplicated, and stored into `bundled_assemblies` and `MonoBundledAssembly::name`. Reduce memory allocations by updating `libxamarin-app.so` to contain a `bundled_assembly_names` array, a'la: struct XamarinAndroidBundledAssembly { int32_t apk_fd; uint32_t data_offset; uint32_t data_size; uint8_t *data; uint32_t name_length; char *name; }; constexpr size_t AssemblyNameWidth; static char assembly_name_1 [AssemblyNameWidth]; static char assembly_name_2 [AssemblyNameWidth]; // … extern "C" XamarinAndroidBundledAssembly bundled_assemblies[] = { { .apk_fd = -1, .data_offset = 0, .data_size = 0, .name_length = 0, .name = assembly_name_1, }, { .apk_fd = -1, .data_offset = 0, .data_size = 0, .name_length = 0, .name = assembly_name_2, }, // … } The `bundled_assemblies` array *doesn't* contain the assembly names detected during packaging time. Rather, it contains *buffers*, each large enough to hold any assembly name. This removes the need to allocate additional memory for assembly names during process startup. (We'll still need to allocate memory for other entries within the `.apk`, such as `.pdb` files.) Additionally, a provision is made for adding more assemblies than those counted and placed in the .`apk` during the build. This may come handy when Xamarin.Android supports split applications (with components placed in different `.apk` files), and also as a simple fail-safe feature should the build miscalculate something. Debug information for assemblies is no longer registered when reading the APK, but rather whenever an assembly load is requested by Mono. Neither the assemblies nor their debug information are mmapped when reading the APK anymore. This is done lazily when assembly load is requested by Mono. Mapping of files after the startup phase is protected with a POSIX semaphore. Additionally, a handful of simple optimizations are implemented: * We no longer query the device's memory page size whenever we `mmap()` a file; the value is instead queried and cached in the `Util` constructor. * The current AppDomain is no longer queried when getting a Mono object's type under .NET 6 * Many log statements are no longer run by default during startup. These changes reduce startup time for a simple plain Xamarin.Android application (one control in a layout) by around 4ms measured for `Displayed` time, and by around 2ms when measured for native runtime startup. For the `Hello Maui` sample from the `maui-samples` repository, the startup time is reduced by ~200ms measured for `Displayed` time (from ~1.6s to ~1.4s), with the same speed up for the native runtime as in the plain Xamarin.Android test above. Performance was measured on a Pixel 3XL phone running Android 12 beta. *Note*: the `Displayed` measurements were found to be **very** unstable during testing on Android 12, with variance between runs reaching 600ms sometimes.
- Loading branch information
Showing
18 changed files
with
1,411 additions
and
1,045 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.