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/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath