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

[Zoltan Varga]

Hi,

  The new JIT in mono 2.4 generates better/smaller code. Here are some
numbers:

1.0 mscorlib produced by mono 2.0: 3724380
1.0 mscorlib produced by mono 2.4: 3364076
2.0 mscorlib produced by mono SVN HEAD: 4255364

Obviously the mscorlib 2.0 stuff still needs some work, but the 1.0 number
is much better.

                 Zoltan

On Wed, Apr 8, 2009 at 4:50 PM, Mantas Puida <mantas at unity3d.com> wrote:

> 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
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090409/7498c943/attachment.html