[Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x

[Mantas Puida]

Hi,


>>
>>
>> Can you give us a breakdown of the size of the many files produced  
>> by mono?
>> Like sizes of the runtime, assemblies after linking/stripping and  
>> AOT'd binaries.

I can't get exact numbers for profile 2.0 because it doesn't work with  
mono-2-0 AOT, so best what I can do is to extrapolate numbers from  
profile 1.0 data.

There are some numbers for profile 1.0 when mono linker is NOT used:

Total size for sample iPhone application made with Unity (it includes  
Unity engine + .NET interface to its functions, physX, libcurl, mono  
runtime and AOTed mscorlib.dll):
15,999,648 bytes

breakdown of this number
a) Mono runtime compiled for ARM  with --enable- 
minimal=jit,reflection_emit,profiler,com option takes 1,790,384 bytes.
b) mscorlib.dll (.dll size 2,081,280 bytes) AOTed code size:  6,703,136
c) UnityEngine.dll (.dll size 376,320 bytes) AOTed code size: 2,313,696


Numbers when mono linker IS used:

Total size for sample iPhone application made with Unity (it includes  
Unity engine + .NET interface to its functions, physX, libcurl, mono  
runtime and AOTed mscorlib.dll):
11,791,088 bytes
breakdown of this number
a) Mono runtime compiled for ARM  with --enable- 
minimal=jit,reflection_emit,profiler,com option takes 1,790,384 bytes.
b) mscorlib.dll (.dll size 1,418,240 bytes, we use less strict than  
default monolinker blacklist for mscorlib) AOTed code size:  4,259,216  
bytes
c) UnityEngine.dll (.dll size 112,128 bytes) AOTed code size: 543,024  
bytes

In general mono linker does great job (when supplied with "optimized"  
blacklists).

Numbers written above are just for empty application and if you add  
something useful like Sockets to you C# scripts then suddenly main  
binary size explodes, reaches 28 MB and more, iPhone SDK linker fails  
to link it, so use of .NET Sockets without mono linker step is  
impossible.

Numbers for application that uses Sockets and goes through mono linker:

Total size: 14,0334,40 bytes.

breakdown of this number
a) Mono runtime compiled for ARM  with --enable- 
minimal=jit,reflection_emit,profiler,com option takes 1,790,384 bytes.
b) mscorlib.dll (.dll size 1,430,016 bytes) AOTed code size:  4,298,672
c) System.Xml.dll (.dll size 557,056 bytes after mono linker) AOTed  
code size:  1,725,872 bytes
d) System.dll (.dll size 130048 bytes after mono linker) AOTed code  
size:  462,416 bytes
e) UnityEngine.dll (.dll size 112,128 bytes) AOTed code size: 543,024

So adding of reference to .NET Socket API adds two new dependencies  
System.dll and System.Xml.dll and ends up with 2.1 MB of additional  
ARM code.

I checked what dependencies would be in the case of 2.0 profile when  
application is using sockets:
Mono.Security.dll - official size 285,696 bytes, after monolinker - N/A*
System.Configuration.dll - official size 117,760 bytes, after  
monolinker - N/A*
System.Security.dll - official size 132,608 bytes, after monolinker -  
N/A*
System.Xml.dll - official size 1,250,304 bytes, after monolinker - N/A*
System.dll - official size 1,467,392 bytes, after monolinker - N/A*
mscorlib.dll - official size 2,508,288 bytes, after monolinker -  
1,640,960.

after monolinker - N/A* means that currently my version of monolinker  
strips these dll too much (no exported types are left), so I can't get  
these numbers without fixing mono linker.

I would estimate that in total it would increase our footprint for  
sample Sockets application at least by 1 MB (bigger mscorlib + 3  
additional dependencies)

Would us help Silverlight profile? I doubt it, because we are using  
shorter mono linker blacklist for mscorlib  and we are achieving  
smaller working size of this lib already.
I think these big binary size (and also big memory footprint) is  
common for other embedded devices, not just iPhone.

I see mscorlib (and other libraries) profile 1.0 as best fit for  
embedded devices.

Miguel, I saw your comment that people who are using profile 1.0   
should stick with mono-2-4 then I would like to ask what about AOT on  
other platforms support? Let's say mono adds PPC AOT support to  
mono-2-6 will it be backported to mono-2-4? If not then I see the  
problem how mono based applications could be developed for small  
devices that currently are not supported by mono-2-4, but maybe will  
be supported in the next versions.

>>
>>
>> There are a lot of optimizations that can be done to reduce  
>> footprint like embedding
>> assemblies content in the AOT'd image in a compact form and  
>> improving the ARM code
>> generator.
>>
>>
>

Embedding something into AOT'd image (mean linked into main app  
binary) makes everything worse in respect to binary size and maybe  
memory footprint.
Maybe I'm missing something in your idea?



Mantas Puida

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090408/b4411eaf/attachment-0001.html