[Mono-list] Re: The Mauve unicode testcase and VM performance

[Jonathan Pryor]

Below...

On Tue, 2004-04-13 at 14:55, Stuart Ballard wrote:
<snip/>
> Interestingly, my installation of mono (from debian sid) doesn't even 
> come with its own libraries AOT'd. I'd have thought that you'd get the 
> best performance by AOT'ing *all* the libraries, including (and 
> especially) the low-level platform ones such as System.dll and 
> System.Xml.dll.

AOT (or pre-JITing) assemblies is not as useful as you'd think.  It has
two primary effects:

  - Reduce memory requirements, as memory doesn't need to be allocated
    for the JITed code
  - Decrease startup time, as (again) the JITing doesn't need to be 
    done.

This isn't without consequence.  Here are some highlights, but see Chris
Brumme's blog[1] for *lots* of details:

  - Fewer opportunities to inline during the JIT, as many methods you'd 
    like to inline will already have been compiled.
  - The real killer: AOT/pre-JIT code is AppDomain-neutral
    - Builds on the above inlining issue
    - Slows down access to class statics fields, as you need to go 
      through an indirection (for AppDomain lookup)
    - The JIT can't emit a direct function call to AOT code

You should (obviously) always run a performance analysis to see what the
impacts of AOT/pre-JIT are, but the general consensus from the .NET
developers is that it should be avoided unless you really can't afford
the startup penalty or the memory requirements.

Personally, I haven't had any problems with startup time under Mono, so
I don't see the point in shipping AOT-compiled assemblies.

 - Jon

[1] http://blogs.msdn.com/cbrumme/