The MonoScenarios dashboard in PowerBI can show "Package Size" which is the total size of an ios .app (or an android .apk), and it can show the file breakdown - which looks like it is the .dll, libSystem.* native PAL libraries, and icu* which is the ICU data.
It would be great if we had a synthetic benchmark which was {total package size} - {sum of *.dll, libSystem*, icu*} that will leave: the size of the native statically linked .app binary (which is not present in the file breakdown at all today) which includes the code produced by the AOT compiler plus libmono (statically linked into the app) and the app glue code (which is essentially constant) and the .aotdata files from the package.
Essentially that difference is all of the native runtime code plus all the native code produced by the AOT compiler.
As a synthetic benchmark it will allow us to detect either increases in the size of the native runtime, or increases in the AOT compiler output, which are both important for the runtime team to be aware of.
The
MonoScenarios
dashboard in PowerBI can show "Package Size" which is the total size of an ios .app (or an android .apk), and it can show the file breakdown - which looks like it is the.dll
,libSystem.*
native PAL libraries, andicu*
which is the ICU data.It would be great if we had a synthetic benchmark which was
{total package size} - {sum of *.dll, libSystem*, icu*}
that will leave: the size of the native statically linked .app binary (which is not present in the file breakdown at all today) which includes the code produced by the AOT compiler plus libmono (statically linked into the app) and the app glue code (which is essentially constant) and the .aotdata files from the package.Essentially that difference is all of the native runtime code plus all the native code produced by the AOT compiler.
As a synthetic benchmark it will allow us to detect either increases in the size of the native runtime, or increases in the AOT compiler output, which are both important for the runtime team to be aware of.