.NET 2.0 Performance Guidelines - Ngen.exe

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman


Contents

Scenarios Where Startup Time Is Paramount Should Consider Ngen.exe for Their Startup Path

Use Ngen.exe for faster startup. Common examples include client scenarios that need the faster startup to be responsive or where you need to improve startup performance of large applications and system services.

Ngen.exe improves startup time for the following reasons:

  • It defers the use of JIT compilation until more infrequent paths start being taken.
  • It potentially allows sharing of pages in memory.
  • It leverages the disk cache to get code loaded quickly.


Scenarios That Benefit from the Ability to Share Assemblies Should Adopt Ngen.exe

Ngen.exe is appropriate for scenarios that benefit from page sharing and working set reduction. Ngen.exe often helps the following scenarios:

  • A line of business executable running on a terminal server (multiple instance).
  • A shared library used by a series of line of business applications (multiple instance).


Scenarios with Limited or No Sharing Should Not Use Ngen.exe

In general, Ngen.exe is not beneficial for scenarios with limited or no sharing, for the following reasons:

  • A dependency on Ngen.exe creates a servicing burden.
  • Single instance applications or libraries gain little benefit. Although code is shareable, no processes will be sharing it because there is only a single instance.
  • The JIT compiler is itself shareable, so the 200 KB cost of loading the JIT compiler is amortized over the applications using it.


Consider Ngen.exe with ASP.NET Version 2.0

At the time of this writing, the .NET Framework 2.0 (code-named "Whidbey") includes a version of Ngen.exe that produces images that can be shared between application domains. Consider using Ngen.exe on assemblies that you share between applications. Make sure you measure performance with and without Ngen.exe.


Measure Performance with and without Ngen.exe

Measure the performance of your application both with and without using Ngen.exe to be sure about the benefits. Make sure that any performance improvements warrant the use of the utility.

Note that Ngen.exe produces code which is optimized for the greatest ability to be shared, sometimes at the expense of raw speed. Ngen.exe can potentially reduce the run-time performance of frequently called procedures because it cannot make some of the optimizations that the JIT compiler can make at run time. It prefers to create code that is shareable; the JIT compiler has no such restriction. You should also consider the extra maintenance required when regenerating native images as required.


Regenerate Your Image When You Ship New Versions

Make sure you regenerate your native image when you ship new versions of your assemblies for bug fixes, updates, or when an external dependency changes.

Ngen.exe emits information including the version of the .NET Framework, CPU type, assembly, and operating system on which the native code was generated. The CLR reverts to JIT compilation if the run-time environment does not match the compiled environment.

Note To avoid having stale assemblies in the native image cache after servicing, you could easily run ngen on the assemblies again when you install a service pack -- just as the setup program would do during the initial installation. Visual Studio .NET provides an easy and straightforward way to implement this behavior by means of defining custom actions in an Microsoft Installer (MSI) package. More information about general .NET deployment concepts and custom actions in particular can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxoriDeploymentConcepts.asp.


Choose an Appropriate Base Address

Choose an appropriate base address for optimum performance. You can specify the base address in the Visual Studio .NET integrated development environment (IDE) in the Project Properties dialog box (in the Optimization section of Configuration Properties). You can also specify it using the /baseaddress option of the Csc.exe or Vbc.exe command line compilers.

Try to avoid collisions between assemblies. A good practice is to allocate an address range three times the size of your MSIL assembly file. You should include extra space to accommodate an increase in assembly size due to bug fixes.

Personal tools