.NET 中预抖动程序集的优点和缺点是什么？
.NET 中预抖动程序集的优点和缺点是什么？
我听说预抖动可以提高性能。什么时候应该预抖动，什么时候不应该预抖动？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
.NET 中预抖动程序集的优点和缺点是什么？
我听说预抖动可以提高性能。什么时候应该预抖动，什么时候不应该预抖动？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（6）
“预编译”或预编译将提高启动时的性能，因为您将跳过该步骤。每次应用程序及其库加载时 .NET JIT 的原因是，它可以在许多平台和架构上运行，并进行最佳优化，而无需管理构建。
因此，您必须权衡是否值得让管理员头痛，以节省应用程序启动和库加载的几秒钟时间。我认为这样做的最常见用例是服务器安装，您倾向于管理很少的机器并且环境非常稳定。例如，您不会为客户端应用程序进行预编译，因为目标环境更难以预测。
"Pre-jitting" or pre-compiling will improve performance, at start up, because you would be skipping that step. The reason that .NET JITs every time an app and its libraries load is so that it can run on many platforms and architectures with the best possible optimizations without the need for managing your builds.
So you have to weigh whether it's worth the admin headaches to save a few seconds on app start up and library loads. I think the most common use case for doing this is for server installs where you tend to manage few machines and the environment is very stable. E.g. you would not pre-compile for client apps because the target environments are much less predictable.
“PRE-JIT”是通过 NGen （从 CIL 预编译为本机映像的过程）。它将编译后的.NET 代码从与平台无关的中间状态转换为特定于平台的阶段。简而言之，它将可以在 Windows、Mac 和 Linux 32 位和 64 位上运行的 .NET 应用程序转换为老式的 EXE 文件 只能在其中之一上运行。
.NET 应用程序被编译为一种名为 MSIL 的中间二进制格式，该格式与平台无关。这意味着应用程序可以由任何平台上的任何CPU运行，只要该平台支持.NET。 .NET 在执行过程中所做的事情称为 JIT。 JIT 将在每次执行之前对代码进行实际使用之前编译一次。这也意味着只有使用的代码才会被编译。
NGen 将为您的应用程序带来性能提升（主要是启动时间），有时非常明显。只要您瞄准正确的平台，NGen 几乎任何东西都是安全的。例如，如果您的应用程序使用 32 位 DLL 文件，则不应将其 NGen 到 64 位，并且如果您的 DLL 文件正在被其他应用程序使用，则不应将其 NGen。
我建议在安装之后（而不是分发之前）运行 NGen，以便您知道该应用程序可以在目标计算机上运行。
"PRE-JIT" is done through NGen (the process of precompiling from CIL to a native image). It will convert the compiled .NET code from the platform-independent intermediate state to a platform specific stage. In plain English, it converts the .NET application that can run on both Windows, Mac and Linux 32-bit and 64-bit to an old-school EXE file that can only run on one of these.
.NET applications are compiled into a intermediate binary format called MSIL that is platform independent. This means that the application can be run by any CPU on any platform as long as the platform supports .NET. What .NET does during execution is called JIT. JIT will compile the code once per execution just before it is actually used. This also means that only the code used will be compiled.
NGen will give your application a performance boost (mostly startup time), sometimes very noticeable. It is safe to NGen just about anything as long as you target the correct platform. For example, if your application uses 32-bit DLL files you should not NGen it to 64-bit, and if your DLL file is in use by other applications you should not NGen it.
I'd recommend running NGen after installation, not before distribution, so that you know the application will work on the target computer.
您是在谈论 NGen 在执行前生成程序集映像吗？ Pre-JIT 在术语上是矛盾的，因为“JIT”意味着即时，就在执行之前。如果您预编译某些内容，根据定义，它不是 JIT 编译。
优点是当程序集或类型首次在代码中加载时，您不会遇到 JITter 可能引入的初始编译延迟。对于极其（可能不明智）的大型程序集/类型，这可能很重要。
缺点包括无法优化某些只能根据运行时条件确定的事情以及必须维护映像的事实。此外，所有使用预生成映像（从 .NET 4 开始）的应用程序和程序集都需要完全信任，并且 CAS 会被忽略。
有关 NGen 的详细信息，请参阅 http://msdn.microsoft.com/en-我们/library/6t9t5wcf.aspx
Are you talking about NGen to generate assembly images before execution? Pre-JIT is a contradiction in terms, since "JIT" means just-in-time, as in right before execution. If you precompile something, it is, by definition, not JIT-ing.
The advantage is that you don't have the initial compilation delay that the JITter can introduce when an assembly or type is loaded for the first time in code. For exceedingly (probably unwisely) large assemblies/types, this can be significant.
The disadvantages include things like the inability to optimize out some things that can only be determined based upon runtime conditions and the fact that you have to maintain the image. In addition, all applications and assemblies using pregenerated images (as of .NET 4) require full trust, and CAS is ignored.
For more information on NGen, see http://msdn.microsoft.com/en-us/library/6t9t5wcf.aspx
它提高了程序的热启动时间。热启动是指程序集数据已在文件系统缓存中，因此磁盘驱动器无需花费时间在磁盘上定位 DLL。与冷启动相反，当程序集以前从未加载过或很久以前加载过时，您会得到冷启动，磁盘驱动器必须首先找到文件。这很慢。您几乎总是只关心冷启动时间，因为这对用户来说非常明显。
这就是问题所在，ngen.exe 创建了一个需要由磁盘驱动器找到的额外文件。包含预编码机器代码 (.ni.dll) 的代码。可能会使冷启动速度变慢。对于“小型”程序集，让 JIT 编译器即时编译代码实际上是有意义的，因为这比磁盘驱动器查找预编译的 DLL 所需的时间要少。到底什么是“小”，即盈亏平衡点，很大程度上取决于磁盘驱动器的寻道速度及其碎片状态。您必须进行试验，但请记住，这不会在另一台机器上很好地重复。虽然像这样的实验本身很困难，但你会很容易得到一个良好的开端。
It improves the warm startup time of your program. A warm start is one where the assembly data is already in the file system cache so no time is spent by the disk drive to locate the DLL on the disk. As opposed to a cold start, one you'll get when the assembly has never been loaded before or was loaded long ago, the disk drive has to find the file first. Which is slow. You almost always only care about cold start time because that's the one that's so noticeable to the user.
Which is the rub, ngen.exe creates an extra file that needs to be found by the disk drive. The one that contains the prejitted machine code (.ni.dll). Possibly making the cold start slower. For 'small' assemblies, it actually makes sense to let the JIT compiler jit the code because that can take less time than needed by the disk drive to find the prejitted DLL. What exactly is 'small', the break-even point, depends a great deal on how fast the disk drive can seek and its fragmentation state. You'd have to experiment, but keep in mind that this won't repeat well on another machine. And that experiments like this are difficult in themselves, you'll easily get a warm start.
我看到了执行的确定性很重要的优势。通常你需要避免像瘟疫一样对时间敏感的执行。有时这是不可避免的。一种情况是与外部硬件交互时，某些行为是异步的，尤其是当有很多步骤串行执行且不重复执行时。这意味着每个步骤都必须进行调整，并且硬件同时做自己的事情（异步通信）
我们总是在安装过程中生成我们的库。我们的图书馆访问不同的硬件设备，其中许多设备最初并不是为自动化而设计的。
I have seen an advantage where determinism of execution is important. Normally you need to avoid timing sensitive execution like the plague. Sometimes it is unavoidable. One scenario is when interacting with external hardware and some of the behavior is asynchronous especially when there are a lot of steps that are executed serially and not repeatedly. This means each step has to be jitted and the hardware is doing its own thing at the same time (asynchronous communication)
We always ngen our libraries during installation. Our libraries access disparate hardware devices many of which were not designed for automation originally.
当您说“预抖动”时，您可能是指使用 NGen (ngen.exe)预编译你的程序集（？）。
使用 NGen 并没有真正的缺点（除了一些额外的磁盘使用字节）。但是，为了使用它，您想要预编译的程序集必须位于 GAC（全局程序集缓存）中。然而，您需要管理员权限才能将它们带到那里。
因此，它不适合您想要通过复制和粘贴轻松部署的应用程序。
是的，使用 NGen 可能会提高应用程序的性能（即使在运行时，因为在 JIT 编译期间会跳过一些优化以节省编译时间）。因此，请尽可能使用 NGen，特别是对于长时间运行的应用程序和您实际想要在本地安装的应用程序。
When you say "pre-jitting", you probably mean using NGen (ngen.exe) to pre-compile your assemblies(?).
Using NGen comes with no real disadvantages (except some additional bytes of disk usage). However, in order to use it, the assemblies you want to pre-compile have to be located in the GAC (Global Assembly Cache). Yet, you will need administrator privileges to get them there.
Thus, it is not suitable for applications you want to deploy very easily via copy&paste.
Yes, using NGen might improve the application's performance (even at runtime as some optimizations are skipped during JIT-compiling to save compiling time). So use NGen whenever possible, especially for long-running applications and applications you actually want to install locally.