C# 你用过ngen.exe吗？

Have you ever used ngen.exe?

提问by Hannoun Yassir

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

这里有人用过ngen吗？在哪里？为什么？是否有任何性能改进？何时何地使用它有意义？

采纳答案by Peter Tate

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.

是的，我已经看到了性能改进。我的测量表明，如果我也将我的程序集放入 GAC，它确实提高了启动性能，因为我的程序集都是强命名的。如果您的程序集是强命名的，那么如果不使用 GAC，NGen 不会有任何区别。这样做的原因是，如果您有不在 GAC 中的强命名程序集，那么 .NET 运行时会通过从磁盘加载整个托管程序集来验证您的强命名程序集未被篡改，以便它可以验证它绕过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.

这对我的应用程序来说不是一个很好的选择，因为我们依赖于我们公司的通用程序集（也是强命名的）。通用程序集被使用许多不同版本的许多产品使用，将它们放在 GAC 中意味着如果我们的应用程序之一没有说“使用特定版本”的通用程序集之一，它将加载 GAC 版本，无论什么版本在其执行目录中。我们认为 NGen 的好处不值得冒险。

回答by Mehrdad Afshari

ngenis 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).

ngen最著名的是改善启动时间（通过消除 JIT 编译）。它可能会提高（通过减少 JIT 时间）或降低应用程序的整体性能（因为某些 JIT 优化将不可用）。

.NET Framework itself uses ngenfor many assemblies upon installation.

.NET Framework 本身ngen在安装时用于许多程序集。

回答by Marc Gravell

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.

我不日常使用它，但它被想要提高性能的工具使用；例如，Paint.NET 在安装程序（或者可能是第一次使用）期间使用 NGEN。某些 MS 工具也有可能（尽管我不确定）。

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 unnecessarywork - but it can't tell that ahead of time.

基本上，NGEN 会预先为装配执行大部分 JIT，因此冷启动时的延迟非常小。当然，在大多数典型用法中，并不是 100% 的代码都被达到了，所以在某些方面这做了很多不必要的工作 - 但它不能提前说出来。

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).

IMO 的缺点是您需要使用 GAC 才能使用 NGEN；我尽量避免使用 GAC，以便我可以使用 robocopy-deployment（到服务器）和 ClickOnce（到客户端）。

回答by Raj

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)

我已经使用它，但仅用于研究目的。仅当您确定部署环境的 cpu 架构时才使用它（它不会改变）

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 编译还不错，如果你有跨多个 cpu 环境的部署（例如经常更新的 Windows 客户端应用程序），那么不要使用 NGEN。那是因为有效的 ngen 缓存取决于许多属性。如果其中之一失败，您的程序集将再次退回到 jit

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)

在这种情况下，JIT 显然是赢家，因为它根据运行的 CPU 架构动态优化代码。（例如，它可以检测是否有超过 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

并且 clr 在每个版本中都变得越来越好，所以简而言之，除非您对部署环境非常确定，否则请坚持使用 JIT-即使如此，您的性能提升也很难证明使用 ngen.exe（可能会在几百毫秒内获得收益）-恕我直言-这不值得付出努力

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

还可以查看关于这个主题的这个非常好的链接 - JIT 编译和性能 - 到 NGen 还是不到 NGen？

回答by Quan Mai

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):

Ngen 主要减少 .NET 应用程序和应用程序工作集的启动时间。但它有一些缺点（来自 Jeffrey Richter 的 CLR Via C#）：

No Intellectual Property Protection

无知识产权保护

NGen'd files can get out of sync

NGen 的文件可能会不同步

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.

由于刚刚列出的所有问题，您在考虑使用 NGen.exe 时应该非常谨慎。对于服务器端应用程序，NGen.exe 几乎没有意义，因为只有第一个客户端请求会受到性能影响；未来的客户端请求会高速运行。此外，对于大多数服务器应用程序，只需要一个代码实例，因此没有工作集优势。

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.

对于客户端应用程序，如果一个程序集被多个应用程序同时使用，NGen.exe 可能有助于缩短启动时间或减少工作集。即使在多个应用程序不使用程序集的情况下，对程序集进行 NGen 也可以改进工作集。此外，如果 NGen.exe 用于所有客户端应用程序的程序集，CLR 将根本不需要加载 JIT 编译器，从而进一步减少工作集。当然，如果只有一个程序集不是 NGen 的，或者一个程序集的 NGen 文件无法使用，JIT 编译器将加载，并且应用程序的工作集会增加。

回答by user3682713

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:

是的。用于 WPF 应用程序以加快启动时间。启动时间从 9 秒缩短到 5 秒。在我的博客中阅读它：

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!

我最近发现了 NGEN 的性能有多棒。我目前使用的应用程序有一个生成的数据访问层 (DAL)。数据库模式非常大，我们还将一些数据（值列表）直接生成到 DAL 中。结果：许多具有许多字段的类和许多方法。在分析应用程序时经常会出现 JIT 开销，但是在对 JIT 编译和 NGEN 进行搜索后，我认为这不值得。安装时开销，管理是我的主要关注点，让我忽略了这些迹象，而是专注于向应用程序添加更多功能。当我们将架构更改为在 64 位机器上运行的“任何 CPU”时，情况变得更糟：我们的应用程序在单个语句中挂起长达 10 秒，分析器仅显示问题区域的 JIT 开销。NGEN 解决了​​这个问题：语句从 10 秒变为 1 毫秒。这个语句不是启动过程的一部分，所以我很想知道 NGEN 对整个应用程序的启动时间可以做什么。它从 8 秒变为 3.5 秒。

结论：我真的建议您尝试使用 NGEN 应用程序！

回答by David Hollinshead

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.

作为 Mehrdad Afshari 关于 JIT 编译的评论的补充。如果通过 XmlSerializer 序列化具有许多属性的类，并且在 64 位系统上使用 SGEN，则 NGEN 组合具有潜在的巨大（在我们的示例中为千兆字节和分钟）效果。

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

这里有更多信息： XmlSerializer 启动 64 位系统上的巨大性能损失，尤其是看到 Nick Martyshchenko 的回答。

回答by maf-soft

Yes, I tried it with a small single CPU-intensive exe and with ngen it was slightly slower!

是的，我用一个小的 CPU 密集型 exe 试了一下，用 ngen 稍微慢了一点！

I installed and uninstalled the ngen image multiple times and ran a benchmark.

我多次安装和卸载 ngen 映像并运行了基准测试。

I always got the following times reproducable +/- 0.1s: 33.9s without, 35.3s with

我总是得到以下可重现的 +/- 0.1 秒时间：没有 33.9 秒，有 35.3 秒