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 (#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
