You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our build process targetting CoreCLR generated marshal methods code that is
only used by our MonoVM runtime. The native code included marshal methods and
class names, as well as assembly image cache which is not supported on CoreCLR.
All of the above data were stored as pointers in the resulting `libxamarin-app.so`,
each pointer being a relocation that has to be fixed up by the system dynamic linker
at application load time. The more relocations exist across the `.so` file, the more
of it the linker has to actually read into memory (instead of just mmapping it and
lazily loading whenever/if the code/data in that section is used).
This PR removes all of that code from the CoreCLR version of `libxamarin-app.so`,
together with a number of native structs supporting the data.
Testing the changes on a `dotnet new maui -sc` application, we can see the following
savings:
* Number of relocations in `libxamarin-app.so` drops from 903 to 394 entries
* `libxamarin-app.so` size drops from:
* arm64: 443648 to 368832 bytes (16.9%)
* x64: 438856 to 360464 bytes (17.9%)
Testing the above MAUI app performance on Pixel 8, we can also see a tiny startup
time decrease by 0.71%. On slower devices and with bigger applications the startup
performance improvement will be bigger (the slower the device's storage, the bigger
time savings)
0 commit comments