Native code generator: ngen.exe

With. net Framework ngen.exe tool can compile il code into native code, when the application is installed on the user's machine. because the code is compiled during installation, the clr jit compiler does not need to compile the Il code at runtime, which can improve the application performance. the ngen.exe tool is interesting in the following two scenarios:

• The application startup speed is improved: Running ngen.exe can improve the startup speed. Because the code has been compiled into native code, you do not need to compile it during runtime.
• Reduce the working sets of applications: if you think that a program assembly is loaded to multiple processes/AppDomains at the same time, running ngen.exe on this Assembly can reduce the working sets of applications, as the ngen.exe tool compiles il into native code, then save the output to a separate file, which can be mapped to multiple process address spaces by memory-mapping at the same time, allowing code sharing, each process/appdomain does not have to copy a code for itself.

When an installer calls ngen.exe to compile an application or assembly, all the assembly or a specific assembly of the application compiles its il code into native code. A new Assembly file containing only nativecode but not ilones will be created by ngen.exe. the new file is put under a folder named c: \ windows \ Assembly \ nativeimages_v2.0.50727_32, the file name contains information about whether the CLR version and native code are compiled for x86 (32-bit windows), x64, or itaninum (64-bit windows.

Now, when the CLR loads an assembly file, the CLR checks whether the corresponding ngen 'd native file exists. If the native file is not found, the clr jit compiles the Il code as usual. however, if the corresponding native file exists, CLR will use the compiled code in the native file, and the functions in the file do not need to be compiled at runtime.

On the surface, it sounds very good. It sounds like if you get all the benefits of hosting code (garbage collection, code verification, type security, etc) without sacrificing the performance of hosting code (JIT compilation), the actual situation is not always so good. The ngen 'd file has several potential problems:

No Intellectual Property Protection: Many people think that ngen files can be published without publishing files containing the original il code, so that their intellectual property rights are more confidential. unfortunately, this is not feasible. during runtime, CLR needs to access the metadata of the Assembly (for some functions, such as reflection and serialization functions ), this requires the release of the Assembly containing Il and metadata. in addition, if, for some reason, the CLR cannot use the ngen 'd file (as described below), the CLR will return to JIT compilation to compile the Assembly's il code, therefore, the Il code must exist.

The ngen file may be out of date: When the CLR loads the ngen 'd file, it compares the previously compiled code with many features of the current execution environment. If any feature does not match, the ngen 'd file cannot be used, and the JIT compiler process must use it. this is a list of some features that must be matched.

N assembly module version ID (mvid)

N version ID of the referenced assembly

N Processor type

N clr version

N build type (release, debug, optimized debug, profiling, etc)

The security requirements of all links must be met at the runtime to allow loading.

When ngen.exe can be run in an upgraded way. When an end user installs a new service pack of. NET Framework, the installation program of the service package will automatically run ngen.exe in a newer model, so that the ngen file remains consistent with the CLR version.

Poor loading performance (relocation/binding): the Assembly file is a standard Windows PE file, and each file contains a preferred base address. many windows developers are familiar with the problem of base address and relocation. You don't have to worry about these issues when compiling code with JIT, because the correct memory address reference will be calculated at runtime.

However, some memory address references of ngen 'd assembly files are calculated statically. When Windows loads an ngen 'd file, it checks whether the file is loaded to the preferred base address, if the file is not loaded to the preferred base address, Windows will reposition the file and modify all memory address references. this is extremely time-consuming because windows must load the entire file and modify many bytes in the file. in addition, the code corresponding to this page file cannot be shared across process boundaries.

Therefore, if you plan to use the ngen Assembly file, you should select the base address (through the/baseaddress command line switch of csc.exe) for the corresponding collection file ). when you ngen an assembly file, the ngen 'd file will be assigned a base address, which requires an algorithm based on the hosted assembly base address. unfortunately, Microsoft has never provided any good guidance to help developers grant the base address. in 64-bit windows, this is not a problem because the address space is sufficient, but for a 32-bit address space, it is almost impossible to select a good base address for each assembly, unless you know exactly what will be loaded into the process and know that the Assembly size will not exceed the previous version.

Poor execution performance: When code is compiled, ngen makes no more assumptions about the execution environment than the JIT compiler. This creates ngen.exe to generate poor code. For example, ngen cannot optimize some CPU commands, access to static fields requires an introduction, because the actual address of the static field must be known at runtime. ngen inserts code everywhere to call the class constructor, because it does not know the order of code execution, and does not know whether the class constructor has been called (See Chapter 8th, class constructor ). some ngen 'd applications are about 5% slower than the Code Compiled by JIT. Therefore, if you plan to use ngen 'd to improve application performance, you should compare the ngen 'd and the non-ngen 'd applications to determine that the ngen 'd version is not slow in actual execution. for some applications, the reduced working set size will improve the performance, so ngen will win in general.

Because of all the problems listed above, you should be very careful when using ngen.exe in the pipeline. for server applications, ngen.exe is of little or even no significance, because only the first customer needs to experience performance decline, and the subsequent customer needs are high-speed. in addition, for most server applications, only one instance of the code is required, so there is no interest in working sets.

For client applications, ngen.exe may be helpful for improving the startup speed or reducing the working set, if the Assembly is used by multiple applications at the same time. even if no application uses one assembly, one ngen assembly will increase the working set. in addition, if ngen.exe is used in the assembly of all client applications, the CLR does not need to load the JIT compiler, further reducing the working set.

Of course, if only one assembly is not ngen 'd or if the ngen 'd file of an assembly cannot be used, the JIT compiler will be loaded and the working set of the application will increase.