Surupa Biswas

As with everything related to performance, you'll want to measure.  For large client applications there is often a significant startup time & working set reduction (such as a 5x reduction in warm startup time) if an application is fully NGen-ed (i.e. NGen-ed application code running against NGen-ed Framework assemblies). Some of the criteria for deciding whether to NGen your application are described here: http://blogs.msdn.com/clrcodegeneration/archive/2007/09/15/to-ngen-or-not-to-ngen.aspx.

An NGen image contains code generated by the JIT compiler as well as data structures that the runtime generates (both are similar to what would be created at application runtime if the NGen image didn't exist). There are some differences in the code generated ahead of time vs. at runtime, but they're mostly minor (examples include generated code for accessing statics - at pre-compilation time we assume the module is going to be loaded as domain-neutral, the cross-module inlining rules are different (NGen rules are more conservative to allow for targeted patching), etc.). NGen enables sharing of code and runtime data structures across processes, so it typically improves both startup time (especially warm startup) and working set.

Background information about NGen can be found in this article: http://msdn.microsoft.com/en-us/magazine/cc163610.aspx. Improvements we're making in CLR 4 are outlined here: http://blogs.msdn.com/clrcodegeneration/archive/2009/05/03/Improvements-to-NGen-in-.NET-Framework-4.aspx and those made in 3.5 SP1 here: http://msdn.microsoft.com/en-us/magazine/dd569747.aspx.