GAC 与 JIT
GAC 下的所有内容都已预编译（ngened）吗？ 如果是这样，那么所有.NET都是预编译的，所以CLR不可能在运行时优化它们？
就像如果您在应用程序中使用 List 一样，CLR 将无法优化 List 本身，而只能优化它在应用程序中的使用方式？ 这是否违背了 JIT 在运行时获得大量优化的目的？ 如此有效地失去了 BCL 的所有潜在优化？
Is everything under the GAC precompiled (ngened)? If so, then all of .NET is precompiled, so it's not possible for the CLR to optimize them at runtime?
Like if you use List in your application then CLR will not be able to optimize the List itself, but only how it's used in your app? Doesn't this defeat the purpose of JIT, to get lots of optimizations at runtime? So effectively losing all the potential optimizations for the BCL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不，GAC 不会自动进行预 JIT 处理； 然而，GAC 是预 JIT 的先决条件。 实际上，只有一小部分内容是预先 JIT 的。 除此之外 - 如果 BCL 是预先 JITted 的，那么这些优化将已经由 NGEN 完成，因此“丢失所有潜在的优化”不是问题。
No, the GAC is not automatically pre-JITted; however, GAC is a pre-requisite to pre-JIT. Actually, only a small minority of things are pre-JITted. Besides which - if the BCL was pre-JITted, then those optimisations would have already been done by NGEN, so the " losing all the potential optimizations" is a non-issue.
GAC 可以包含非 ngen 代码（使用 ngen 时它必须包含该代码以及本机映像，因为 ngen 映像不包含所有所需的元数据）。 Ngen 代码需要将 dll 安装在 GAC 中才能有效运行（从技术上讲，您可以不安装它，但结果名称验证会触发对 dll 的完全读取无论如何，这可能会使您的启动时间< em>更糟）。
在 3.5 sp1 之前，ngen 编译与运行时肯定略有不同，请参阅这篇文章< /a> 了解更多详细信息。 我想这对于 3.5SP1 来说仍然适用，因为这些问题很难解决。
由于 ngen 只真正给你带来了两个巨大的胜利，你应该考虑其中一个/两个在你的场景中是否重要，以证明与其使用相关的复杂性和成本是合理的。
我建议这篇文章详细介绍了 2.0 ngen 中的一些更改一本好书，它涵盖了诸如硬绑定之类的内容，这是一个很大的改进，并链接到有关编写高效托管代码的优秀通用文档，尽管它受到了链接腐烂的影响，请参阅msdn 第 5 章 它引用了。 （请注意，该文档已过时，但许多主题仍然有效）
The GAC can contain non-ngen'd code (it must contain it as well as the native images when using ngen since ngened images do not contain all the needed meta data). Ngen'd code requires the dll be installed in the GAC to function efficiently (technically you can do it without but the resulting name verification triggers full read of your dll anyway which is likely to make your startup time worse).
Pre 3.5 sp1 the ngen compilation was definitely fractionally different from the runtime one see this article for some more details. I would imagine this still holds true for 3.5SP1 since those issues are hard to solve.
Since ngen only really gives you two big wins you should consider whether either/both are significant in your scenario to justify the complexity and cost associated with their use.
I suggest This article detailing some of the changes in the 2.0 ngen is a good read, it covers things like hard binding which is a big improvement and links in to the excellent general documentation on writing efficient managed code though it has suffered from link rot see msdn Chapter 5 it refers to. (note that that doc is old but many of the themes are still valid)
不，全局程序集缓存未预编译。
该框架的较新版本确实有一个在后台运行的优化服务，该服务会进行一些预编译。 但当它在目标系统上运行时，它所做的所有预编译都会针对该特定系统进行优化。
No, the global assembly cache is not precompiled.
Newer versions of the framework do have an optimization service running in the background that does some precompilation. But as it runs on the target system all the precompilation it does is optimized for that specific system.
如果从 GAC 加载程序集，则会跳过强名称验证，因为该程序集已被验证。 GAC 的另一个优点是文件保护（仅限管理员）。
NGEN 有自己的本机图像存储。 在不首先将程序集放入 GAC 中的情况下使用 NGEN 是有点意义的。 在这种情况下，加载程序集将导致验证其 SN 签名，这意味着每次加载程序集时都会重新创建加密哈希。
使用 ngen 时的最佳实践是将程序集也放入 GAC 中。
If an assembly is loaded from the GAC the strong-name verification is skipped because the assembly has already been verified. Another advantage of the GAC is file protection (admin-only).
NGEN has its own storage for native images. It makes a little sense to use NGEN without putting an assembly in the GAC first. In such a case loading the assembly would cause to verify its SN signature, which means that the cryptographic hash is recreated each time the assembly is loaded.
The best practice when using ngen is to put assemblies in the GAC as well.