One of the most often cited reasons to not use .NET is that it is initially compiled to an intermediary language (MSIL) and has to be recompiled every time you run it. In many high performance environments this wasted time is simply unacceptable. To combat this Microsoft released a tool with .NET 1.1 called NGen (Native Image Generator) which allows you do precompile MSIL to real machine code and in so doing avoid much of the extra run-time overhead.

What Do I Get From Generating Native Images?


-Faster Program Load Time
-Reduced Memory Footprint
-Code Sharing Between Processes

Important Things to Note About Performance:

-Large applications generally benefit from compilation to native images. Small applications generally do not benefit.
-For long-running applications, run-time JIT compilation performs slightly better than native images.

Also, because of the great number of variables involved, it is important to contrast the performance of your application in native image format with that of your MSIL executable:

Performance of native images depends on a number of factors that make analysis difficult, such as code and data access patterns, how many calls are made across module boundaries, and how many dependencies have already been loaded by other applications. The only way to determine whether native images benefit your application is by careful performance measurements in your key deployment scenarios.
There are a lot of small things you can do to help speed up your application with NGen. It's definitely worth reading the MSDN documentation if you are trying to squeeze out every last drop of performance.

NGen 1.1 Vs 2.0+


In the 1.1 release NGen had a number of limitations which severely limited it's usefulness.  The wost limitations were the lack of support for application domains and hardbinding. Another problem was that in 1.1 the command was applied to individual assemblies only which caused all kinds of dependency nightmares.

All of these problems have since been solved. NGen in 2.0 is run on an entire program instead of a single assembly. This eliminates many of the dependency problems of 1.1 and makes the process a whole lot easier.

Using NGen in 2.0


The default case for NGen is extremely simple:
ngen install ClientApp.exe
This will generate native images for ClientApp.exe and all of it's dependencies. This process can be quite slow. For larger applications you may wish to use the /queue option which will queue up ClientApp.exe, and all of it's dependencies, so that they will be converted by the Native Image Service. This will happen in the background, at the service's earliest convenience.

Once the native image is generated it will be stored in the native image cache and used automatically.

For more specific Information on NGen check out the MSDN article. Bart De Smet also has a blog entry on this topic which will walk you through the ins and outs of all the command line arguments.

 

Edit:
On dotNetKicks Sam Allen pointed out that he has written an article on building an MSI installer class which automatically runs makes a native image at install time.