Runtime Performance Ideas

Jump to bottom

Radek Doulik edited this page Sep 17, 2018 · 21 revisions

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.

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)

Improvements in progress

PR 2153 Generate JNI marshal methods
PR 1886 Do not fallback in GetJavaToManagedType

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