Nbsp;   The Native Code Generator Tool: NGen.exe

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. Because 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 applica- tion’s performance. The NGen.exe tool is interesting in two scenarios:

■ Improving an application’s startup timeRunning 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 setIf you believe that an assembly will be loaded into multiple processes simultaneously, running NGen.exe on that assembly can reduce the ap- plications’ 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 needs its own copy of the code.

When a setup program invokes NGen.exe on an application or a single assembly, all of the assem- blies for that application or the one specified assembly have their IL code compiled into native code. A new assembly file containing only this native code instead of IL code is created by NGen.exe. This new file is placed in a folder under the directory with a name like %SystemRoot%\Assembly\ NativeImages_v4.0.#####_64. The directory name includes the version of the CLR and infor- mation denoting whether the native code is compiled for 32-bit or 64-bit versions of Windows.

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:

■ No intellectual property protectionMany 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. At run time, the CLR requires access to the assembly’s metadata (for functions such as reflection and serialization); this requires that the assemblies that contain IL and metadata be shipped. In addition, if the CLR can’t use the NGen’d file for some reason (described next), the CLR gracefully goes back to JIT compiling the assembly’s IL code, which must be available.

■ NGen’d files can get out of syncWhen 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. Here is a partial list of characteristics that must match:

• CLR version: This changes with patches or service packs.

• CPU type: This changes if you upgrade your processor hardware.

• Windows operating system version: This changes with a new service pack update.

• Assembly’s identity module version ID (MVID): This changes when recompiling.

• Referenced assembly’s version IDs: This changes when you recompile a referenced assembly.

• Security: This changes when you revoke permissions (such as declarative inheritance, de- clarative link-time, SkipVerification, or UnmanagedCode permissions), that were once granted.

■ Inferior execution-time performanceWhen 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 instruc- tions; 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. (See Chapter 8, “Methods,” for more about class constructors.) Some NGen’d applications actually perform about 5 percent slower when compared to their JIT-compiled counterpart. So, if you’re considering using NGen.exe to improve the performance of your application, you should compare NGen’d and non-NGen’d versions to be sure that the NGen’d version doesn’t actually run slower! For some applications, the reduction in working set size improves performance, so using NGen can be a net win.

Due to all of the issues just listed, you should be very cautious when considering the use of NGen.exe. For server-side applications, NGen.exe makes little or no sense because only the first client request experiences a performance hit; future client requests run at high speed. In addition, for most server applications, only one instance of the code is required, so there is no working set benefit.

For client applications, NGen.exe might make sense to improve startup time or to reduce working set if an assembly is used by multiple applications simultaneously. Even in a case in which an assembly is not used by multiple applications, NGen’ing an assembly could improve working set. Moreover,

if NGen.exe is used for all of a client application’s assemblies, the CLR will not need to load the JIT compiler at all, reducing working set even further. Of course, if just one assembly isn’t NGen’d or if an assembly’s NGen’d file can’t be used, the JIT compiler will load, and the application’s working set increases.

For large client applications that experience very long startup times, Microsoft provides a Man- aged Profile Guided Optimization tool (MPGO.exe). This tool analyzes the execution of your appli- cation to see what it needs at startup. This information is then fed to the NGen.exe tool in order to better optimize the resulting native image. This allows your application to start faster and with a re- duced working set. When you’re ready to ship your application, launch it via the MPGO tool and then exercise your application’s common tasks. Information about the parts of your code that executed is written to a profile, which is embedded within your assembly file. The NGen.exe tool uses this profile data to better optimize the native image it produces.

Date: 2016-03-03; view: 596