| Previous | Next |
| ERROR_SYSTEM_NEEDS_REMEDIATION | ERROR_RESILIENCY_FILE_CORRUPT |
ERROR_APPX_INTEGRITY_FAILURE_CLR_NGEN
Unlike statically compiled binaries, NGen images are tied to the machine where they are created and hence cannot be deployed. Instead, the application's installer needs to issue commands to create native images for the specific assemblies on the client machine at setup time. Also unlike traditional binaries, NGen images merely form a cache-managed applications will continue to run correctly even if all the NGen images are deleted. Of course, there will be a performance hit if that happens, but there will be no correctness issues. On the other hand, managed applications may fail to run correctly if the MSIL assemblies are deleted once they have been compiled into NGen images.
Typically, methods in managed executables are just-in-time (JIT) compiled. The machine code generated by the JIT compiler is thrown away once the process running that executable exits; therefore, the method must be recompiled when the application is run again. Moreover, the generated code is tied to the process that created it and cannot be shared between processes that are running the same application.
These characteristics of .NET JIT compilation can have performance drawbacks. Fortunately, NGen (native image generation) offers some relief. NGen refers to the process of precompiling Microsoft® intermediate language (MSIL) executables into machine code prior to execution time. This results in two primary performance benefits. First, it reduces application startup time by avoiding the need to compile code at run time. Second, it improves memory usage by allowing for code pages to be shared across multiple processes.
Why Use NGen?
NGen typically improves the warm startup time of applications, and sometimes the cold startup time as well. Cold startup time refers to the time taken to start an application soon after a machine reboot, such that the application is being launched for the first time after that reboot. Warm startup time, on the other hand, is the time taken to start the application given that it was launched in the recent past (and there were no reboots in between).
Cold startup time is primarily dominated by the number of pages that need to be fetched from disk. The improvement in cold startup time while using NGen can be attributed largely to the fact that pages of MSIL that need to be touched during compilation no longer need to be accessed at execution time.
Improvements in warm startup time come from reusing pages of the NGen images that were brought in when the application had been running earlier. This is especially beneficial to large client-side UI applications where startup time is critical to the user experience.
NGen also improves the overall memory usage of the system by allowing different processes that use the same assembly to share the corresponding NGen image among them, as shown in Figure 1. This can be very useful in both client and server scenarios in which the total memory footprint must be minimized. A classic example is the Terminal Services scenario in which a large number of users might be logged in and running the same application at the same time. If you're building libraries or other reusable components, you may also want to use NGen so that applications using your components can share the generated code pages.
It is important to note that NGen does not always improve the cold startup time of applications, since NGen images are larger than MSIL assemblies. The only way to determine whether cold startup time and working set will improve or degrade with NGen for specific scenarios is to actually measure them. (More on performance measurement later.)