Inside CLR ngen.exe tool

The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead using the just-in-time (JIT) compiler to compile the original assembly.

The NGen.exe tool that ships with the .NET Framework can be used to compile IL code to native code when an application is installed on a user’s machine. Since the code is compiled at install time, the CLR’s JIT compiler does not have to compile the IL code at run time, and this can improve the application’s performance. The NGen.exe tool is interesting in two scenarios:

Improving an application’s startup time
Running NGen.exe can improve startup time because the code will already be compiled into native code so that compilation doesn’t have to occur at run time.

Reducing an application’s working set
If you believe that an assembly will be loaded into multiple processes/AppDomains simultaneously, running NGen.exe on that assembly can reduce the applications’ working set. The reason is because the NGen.exe tool compiles the IL to native code and saves the output in a separate file. This file can be memory-mapped into multiple process address spaces simultaneously, allowing the code to be shared; not every process/AppDomain needs its own copy of the code.

Now, whenever the CLR loads an assembly file, the CLR looks to see if a corresponding NGen’d native file exists. If a native file cannot be found, the CLR JIT compiles the IL code as usual. However, if a corresponding native file does exist, the CLR will use the compiled code contained in the native file, and the file’s methods will not have to be compiled at run time. On the surface, this sounds great! It sounds as if you get all of the benefits of managed code (garbage collection, verification, type safety, and so on) without all of the performance problems of managed code (JIT compilation). However, the reality of the situation is not as rosy as it would first seem.

There are several potential problems with respect to NGen’d files:

1. No Intellectual Property Protection Many people believe that it might be possible to ship NGen’d files without shipping the files containing the original IL code thereby keeping their intellectual property a secret. Unfortunately, this is not possible
2. NGen’d files can get out of sync :When the CLR loads an NGen’d file, it compares a number of characteristics about the previously compiled code and the current execution environment. If any of the characteristics don’t match, the NGen’d file cannot be used, and the normal JIT compiler process is used instead.
3. Inferior Load-Time Performance (Rebasing/Binding) :
   Assembly files are standard Windows PE files, and, as such, each contains a preferred base address. Many Windows developers are familiar with the issues surrounding base addresses and rebasing
4. Inferior Execution-Time Performance :
   When compiling code, NGen can’t make as many assumptions about the execution environment as the JIT compiler can. This causes NGen.exe to produce inferior code. For example, NGen won’t optimize the use of
   certain CPU instructions; it adds indirections for static field access because the actual address of the static fields isn’t known until run time. NGen inserts code to call class constructors everywhere because it doesn’t know the order in which the code will execute and if a class constructor has already been called.

 Ngen.exe has changed significantly in the .NET Framework version 2.0:

1) Installing an assembly also installs its dependencies, simplifying the syntax of Ngen.exe.
2) Native images can now be shared across application domains
3) A new action, update, re-creates images that have been invalidated.
4) Actions can be deferred for execution by a service that uses idle time on the computer to generate and install images.
5) Some causes of image invalidation have been eliminated.

 
Usage: ngen <action> [args] [/nologo] [/silent] [/verbose]
       ngen /? or /help
    /nologo    - Prevents displaying of logo
    /silent    - Prevents displaying of success messages
    /verbose   - Displays verbose output for debugging
Actions:
    ngen install <assembly name> [scenarios] [config] [/queue[:[1|2|3]]
        Generate native images for an assembly and its dependencies
        and install them in the Native Images Cache
        If /queue is specified compilation job is queued up.  If a priority
        is not specified, the default priority used is 3.
    ngen uninstall <assembly name> [scenarios] [config]
        Delete the native images of an assembly and its dependencies from
        the Native Images Cache.
    ngen update [/queue]
        Update native images that have become invalid
        If /queue is specified compilation jobs are queued up.
    ngen display [assembly name]
        Display the ngen state
    ngen executeQueuedItems [1|2|3]
        Executes queued compilation jobs.
        If priority is not specified all queued compilation jobs are done.
        If priority is specified compilation jobs with greater or equal.
        priority than the specified are done.
    ngen queue [pause|continue|status]
        Allows the user to pause and continue the NGen Service, and to
        query its status.
Scenarios:
    /Debug          - Generate images that can be used under a debugger
    /Profile        - Generate images that can be used under a profiler
    /NoDependencies - Generate the minimal number of native images
                      required by this scenario
Config:
    /ExeConfig:<path to exe> - Use the configuration of the specified
                 executable assembly
    /AppBase:<path to appbase directory> - Use the specified directory as
                 the appbase

Sources :
MS Press ,CLR via C# 2th Edition , Jeffrey Richter
http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

Knowledge is power !