Have you ever used ngen.exe?

问题

Has anybody here ever used ngen? Where? why? Was there any performance improvement? when and where does it make sense to use it?

回答1:

Yes, I've seen performance improvements. My measurements indicated that it did improve startup performance if I also put my assemblies into the GAC since my assemblies are all strong named. If your assemblies are strong named, NGen won't make any difference without using the GAC. The reason for this is that if you have strong named assemblies that are not in the GAC, then the .NET runtime validates that your strong named assembly hasn't been tampered with by loading the whole managed assembly from disk so it can validate it circumventing one of the major benefits of NGen.

This wasn't a very good option for my application since we rely on common assemblies from our company (that are also strong named). The common assemblies are used by many products that use many different versions, putting them in the GAC meant that if one of our applications didn't say "use specific version" of one of the common assemblies it would load the GAC version regardless of what version was in its executing directory. We decided that the benefits of NGen weren't worth the risks.

回答2:

I don't use it day-to-day, but it is used by tools that want to boost performance; for example, Paint.NET uses NGEN during the installer (or maybe first use). It is possible (although I don't know for sure) that some of the MS tools do, too.

Basically, NGEN performs much of the JIT for an assembly up front, so that there is very little delay on a cold start. Of course, in most typical usage, not 100% of the code is ever reached, so in some ways this does a lot of unnecessary work - but it can't tell that ahead of time.

The downside, IMO, is that you need to use the GAC to use NGEN; I try to avoid the GAC as much as possible, so that I can use robocopy-deployment (to servers) and ClickOnce (to clients).

回答3:

Ngen mainly reduces the start-up time of .NET app and application's working set. But it's have some disadvantages (from CLR Via C# of Jeffrey Richter):

No Intellectual Property Protection

NGen'd files can get out of sync

Inferior Load-Time Performance (Rebasing/Binding)

Inferior Execution-Time Performance

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.

回答4:

ngen is mostly known for improving startup time (by eliminating JIT compilation). It might improve (by reducing JIT time) or decrease overall performance of the application (since some JIT optimizations won't be available).

.NET Framework itself uses ngen for many assemblies upon installation.

回答5:

i have used it but just for research purpose. use it ONLY if you are sure about the cpu architecture of your deployment environment (it wont change)

but let me tell you JIT compilation is not too bad and if you have deployments across multiple cpu environments (for example a windows client application which is updated often) THEN DO NOT USE NGEN. thats coz a valid ngen cache depends upon many attributes. if one of these fail, your assembly falls back to jit again

JIT is a clear winner in such cases, as it optimizes code on the fly based on the cpu architecture its running on. (for eg it can detect if there are more then 1 cpu)

and clr is getting better with every release, so in short stick with JIT unless you are dead sure of your deployment environment - even then your performance gains would hardly justify using ngen.exe (probably gains would be in few hundred ms) - imho - its not worth the efforts

also check this real nice link on this topic - JIT Compilation and Performance - To NGen or Not to NGen?

回答6:

Yes. Used on a WPF application to speed up startup time. Startup time went from 9 seconds to 5 seconds. Read about it in my blog :

I recently discovered how great NGEN can be for performance. The application I currently work on has a data access layer (DAL) that is generated. The database schema is quite large, and we also generate some of the data (list of values) directly into the DAL. Result: many classes with many fields, and many methods. JIT overhead often showed up when profiling the application, but after a search on JIT compiling and NGEN I though it wasn’t worth it. Install-time overhead, with management my major concern, made me ignore the signs and focus on adding more functionality to the application instead. When we changed architecture to “Any CPU” running on 64 bit machines things got worse: We experienced hang in our application for up to 10 seconds on a single statement, with the profiler showing only JIT overhead on the problem-area. NGEN solved the problem: the statement went from 10 seconds to 1 millisecond. This statement was not part of the startup-procedure, so I was eager to find out what NGEN’ing the whole application could do to the startup time. It went from 8 seconds to 3.5 seconds.

Conclusion: I really recommend giving NGEN a try on your application!

回答7:

As an addition to Mehrdad Afshari's comment about JIT compilation. If serializing a class with many properties via the XmlSerializer and on a 64-bit system a SGEN, NGEN combo has a potentially huge (in our case gigabytes and minutes) effect.

More info here: XmlSerializer startup HUGE performance loss on 64bit systems see Nick Martyshchenko's answer especially.