Runtime Performance Ideas

Runtime performance is important for our users. We care about the startup performance and also the performance in general.

Measurements

Type of measurements we use to analyze the runtime performance

• Regular test measurements with time and size plots

• Profiler - we use manual measurements with profiler to analyze the performance of the managed code. Usually the calls, alloc and sample reports.

  • NDK native profiler can be used to profile Mono + Xamarin.Android native runtimes

Findings

• Not preloading all app assemblies during runtime init (Java_mono_android_Runtime_init in monodroid-glue.cc) buys us 100ms.
• Application started via an Intent is ~2.5x slower than one started "normally" by clicking the app icon in the launcher (sometimes even slower than that - e.g. logger initialization in managed code takes ~4ms with normal startup, 28ms with the "Intent" one). Measured on Pixel 3 XL. Nobody knows why it happens, yet.
• Xamarin.Forms apparently attempt to reflection-load all the assemblies in the app, this causes our savings in the native init code to disappear once we hit the managed land.

Ideas

• New JNI marshal methods to speedup startup by avoiding System.Reflection.Emit use. That would hopefully provide faster marshal methods registration and reduce the JIT time and apk size

• Profiled AOT - the idea is to AOT just the startup code to make apk size smaller, while preserve fast startup. (AOT startup is about 2 times faster)

• Run some of the regular tests with profiling. Process and use the data in the time plots

• Assemblies loading

  • do not try to load AOT'ed assemblies when we know they are not in the apk (Release configuration)
  • Let Mono know where it can look for assemblies in general (e.g. skip the GAC, skip compile time host locations). We know exactly where the assemblies may be. This would limit calls to monodroid_dlopen and dlopen

• Measure performance regularly on devices as well - today we only use Android emulator to run the tests by the build bots. It might be also worth to run performance measurements on dedicated machine and collect data on mobile devices and emulators. That might be more stable compared to the build bots.

• Improve the way we use the typemap.{jm,mj} files. Currently they use the bsearch and strcmp to compare strings, thus comparing strings continuously character by character and the lookup function is called very often. It might be faster to enhance the typemap format with a precalculated hash of the string and then use an int -> typemap_entry dictionary/map to cut the number of hash calculations in half. With C++ we could use for instance sparsehash to make the comparisons faster than they are now.

• p/invoke optimization Mono runtime uses dlsym to look up native functions in DSOs whenever the p/invoke is used. The same thing happens on Android, especially for all the __Internal externals. However, this is completely unnecessary since by the time Mono runtime is initialized by us, we already know addresses of all the exported functions. The idea is to inform Mono about the addresses of those functions so that it can skip the lookup. This requires changes to the Mono runtime.

• Xamarin.Android runtime uses JNI's FindClass method quite a lot to look up Java classes during startup. This might not be necessary if we store references to those classes in the Java mono.android.Runtime class which calls into our native initialization sequence. This way we can skip the "reflection" part and let ART do the job for us before our native code runs.

• Limit unnecessary logging. We currently call e.g. log_info (LOG_DEFAULT, ...) a lot without checking whether the DEFAULT category is enabled. This is costly, as logcat is costly, but it also sometimes requires code to run in order to prepare parameters for the logger call, only to discard everything because the category is disabled. We need to actively check whether a category is enabled before logging. Doesn't apply to log_warn or higher.

• Stop reading Android system properties on startup (and in general - we shouldn't need to use them at all in our runtime code). Android implements property store as a kernel driver and accessing the store is full of context switches, uses socket polling as well as puts up write barriers. We should replace use of system properties with a set of files to store them in the application directory.

Improvements in progress

• PR 1886 Do not fallback in GetJavaToManagedType
• PR 2515 Runtime startup performance improvements
• PR 2454 jnimarshalmethod-gen.exe Windows support

Planned improvements

• Fix Bcl test measurements and add them to the plots again

• Generate and use JNI marshal methods for constructors used in the ConstructorBuilder to avoid last System.Reflection.Emit use

Finished improvements

• PR 2153 Generate JNI marshal methods
• PR 2008 Faster native members registration
• PR 1890 Use the faster java type name mapping
• PR 1872 Avoid using Guid.NewGuid () for dynamic constructor names
• PR 1868 Avoid using Guid.NewGuid () for dynamic method names