Export (0) Print
Expand All

Native Images

.NET Framework 4.5

The simplest form of native code generation occurs when the just-in-time (JIT) compiler compiles Microsoft intermediate language (MSIL) code from an assembly into native code for the local machine, immediately before a method is executed for the first time. This native code is temporary; it is stored in the memory space of the running process, which is reclaimed by the operating system when the process ends. Thus, the native code is regenerated each time a new process needs it.

By contrast, the Native Image Generator (Ngen.exe) loads an assembly and invokes the JIT compiler to compile an entire assembly into native code. The resulting native image is a true Win32 portable executable (PE) file, which is stored in a hard disk location called the native image cache. When an application needs the assembly, the common language runtime (CLR) loads the native image instead of loading the original assembly and the JIT compiler. The CLR maintains information about which assemblies have native images, and additional information such as whether the image was created for debugging purposes.

Native images can provide performance improvements in two areas: improved memory use and reduced startup time.

Native images can significantly improve memory use when code is shared between processes. Native images are Windows PE files, so a single copy can be shared by multiple processes. By contrast, native code produced by the JIT compiler is stored in private memory and cannot be shared.

Applications that are run under Terminal Server also benefit from shared code pages.

Not loading the JIT compiler saves a fixed amount of memory for each application instance.

Precompiling assemblies with Ngen.exe can improve the startup time for some applications. In general, gains can be made when applications share component assemblies, because after the first application has been started the shared components are already loaded for subsequent applications. Cold startup, in which all the assemblies in an application must be loaded from the hard disk, does not benefit as much from native images because the hard disk access time predominates.

Hard binding can affect startup time, because all images that are hard bound to the main application assembly must be loaded at the same time.

If your application doesn't run in a scenario that supports automatic generation of native images (see Creating Native Images for a description of these scenarios), the following considerations may help you evaluate whether to generate native images for your application manually:

  • Native images load faster than MSIL because they eliminate the need for many startup activities, such as JIT compilation and type-safety verification.

  • Native images require a smaller initial working set because there is no need for the JIT compiler.

  • Native images enable code sharing between processes.

  • Native images require more hard disk space than MSIL assemblies and may require considerable time to generate.

  • Native images must be maintained:

    • Images must be regenerated when the original assembly or one of its dependencies is serviced.

    • A single assembly may need multiple native images for use in different applications or different scenarios. For example, the configuration information in two applications might result in different binding decisions for the same dependent assembly.

    • Native images must be generated by an administrator; that is, from a Windows account in the Administrators group.

In addition to these general considerations, you should consider the nature of your application when determining whether native images might provide a performance benefit:

  • If your application runs in an environment that uses many shared components, native images allow the components to be shared by multiple processes.

  • If your application uses multiple application domains, native images allow code pages to be shared across domains.

  • If your application will be run under Terminal Server, native images allow sharing of code pages.

  • 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. (Hard binding can mitigate this performance difference to some degree.)

© 2014 Microsoft