你用过ngen.exe吗？
这里有人用过ngen吗？ 在哪里？ 为什么？ 性能有任何改进吗？ 何时何地使用它才有意义？
Has anybody here ever used ngen? Where? why? Was there any performance improvement? when and where does it make sense to use it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我并不日常使用它，但它被那些想要提高性能的工具所使用； 例如，Paint.NET 在安装过程中（或者可能是第一次使用）使用 NGEN。 有些 MS 工具也有可能（尽管我不确定）。
基本上，NGEN 预先执行装配的大部分 JIT，因此冷启动时几乎没有延迟。 当然，在大多数典型用法中，不会达到 100% 的代码，因此在某些方面，这会执行许多不必要的工作 - 但它无法提前告知这一点。
IMO 的缺点是您需要使用 GAC 才能使用 NGEN； 我尝试尽可能避免 GAC，以便可以使用 robocopy-deployment（到服务器）和 ClickOnce（到客户端）。
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).
是的，我已经看到了性能的改进。 我的测量表明，如果我也将我的程序集放入 GAC 中，它确实会提高启动性能，因为我的程序集都是强命名的。 如果您的程序集是强命名的，那么在不使用 GAC 的情况下，NGen 不会产生任何影响。 原因是，如果您的强命名程序集不在 GAC 中，则 .NET 运行时会通过从磁盘加载整个托管程序集来验证您的强命名程序集是否未被篡改，以便验证它是否绕过NGen 的主要优势之一。
对于我的应用程序来说，这不是一个很好的选择，因为我们依赖于我们公司的通用程序集（也是强命名的）。 通用程序集被许多使用许多不同版本的产品所使用，将它们放入 GAC 中意味着如果我们的应用程序之一没有说通用程序集之一的“使用特定版本”，则无论什么版本都会加载 GAC 版本版本位于其执行目录中。 我们认为 NGen 的好处不值得冒风险。
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.
Ngen主要减少.NET应用程序和应用程序工作集的启动时间。 但它有一些缺点（来自 Jeffrey Richter 的 CLR Via C#）：
没有知识产权保护
NGen 的文件可能会不同步
加载时性能较差（变基/绑定）
执行时性能较差
由于所有问题列出，您在考虑使用时应该非常谨慎
NGen.exe。 对于服务器端应用程序，NGen.exe 几乎没有任何意义，因为只有
第一个客户端请求遇到性能影响； 未来的客户端请求会高速运行。 在
另外，对于大多数服务器应用程序来说，只需要一个代码实例，因此没有
工作集的好处。
对于客户端应用程序，NGen.exe 可能有助于缩短启动时间或减少启动时间
如果程序集同时被多个应用程序使用，则为工作集。 即使在一个案例中
一个程序集不被多个应用程序使用，NGen'ing 程序集可以改进
工作集。 此外，如果 NGen.exe 用于客户端应用程序的所有程序集，则 CLR
根本不需要加载 JIT 编译器，进一步减少工作集。 当然，如果
只有一个程序集未经过 NGen 处理，或者如果无法使用程序集的 NGen 处理文件，则 JIT 编译器
将加载，并且应用程序的工作集会增加。
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.
ngen主要以缩短启动时间（通过消除 JIT 编译）而闻名。 它可能会提高（通过减少 JIT 时间）或降低应用程序的整体性能（因为某些 JIT 优化不可用）。.NET Framework 本身在安装时对许多程序集使用
ngen。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)..NET Framework itself uses
ngenfor many assemblies upon installation.我已经使用过它，但仅用于研究目的。 仅当您确定部署环境的 cpu 架构（它不会改变）时才使用它，
但让我告诉您 JIT 编译还不错，并且如果您跨多个 cpu 环境进行部署（例如更新的 Windows 客户端应用程序）经常）那么就不要使用 NGEN。 那是因为有效的 ngen 缓存取决于许多属性。 如果其中一个失败，您的程序集将再次回退到 jit。
在这种情况下，JIT 显然是赢家，因为它根据运行的 cpu 架构动态优化代码。 （例如，它可以检测是否有超过 1 个 cpu）
并且 clr 在每个版本中都变得更好，因此简而言之，除非您非常确定您的部署环境，否则请坚持使用 JIT - 即使这样您的性能提升也很难证明使用 ngen 是合理的。 exe（可能收益会在几百毫秒内） - 恕我直言 - 它不值得付出努力，
还请检查有关此主题的这个真正好的链接 - JIT 编译和性能 - 到 NGen 还是不到 NGen？
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?
是的。 用于 WPF 应用程序以加快启动时间。 启动时间从 9 秒缩短到 5 秒。 在我的博客中阅读相关内容：
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 :
作为 Mehrdad Afshari 关于 JIT 编译的评论的补充。 如果通过 XmlSerializer 序列化具有许多属性的类，并且在 64 位系统上，SGEN、NGEN 组合具有潜在的巨大（在我们的例子中为千兆字节和分钟）效果。
更多信息请点击这里：
XmlSerializer 在 64 位系统上启动巨大的性能损失请参阅 Nick Martyshchenko 的回答尤其。
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.
是的，我用一个小型的 CPU 密集型 exe 进行了尝试，但使用 ngen 时速度稍微慢一些！
我多次安装和卸载 ngen 映像并运行基准测试。
我总是得到以下可重现的时间 +/- 0.1 秒：
33.9s 无，
35.3秒与
Yes, I tried it with a small single CPU-intensive exe and with ngen it was slightly slower!
I installed and uninstalled the ngen image multiple times and ran a benchmark.
I always got the following times reproducable +/- 0.1s:
33.9s without,
35.3s with