即时编译与提前编译相比有何优点？

我最近一直在思考这个问题，在我看来，最大的优势是JIT编译或多或少应该归因于中间格式，而抖动本身并不是生成代码的好方法。

那么主要就是这些pro-JIT我经常听到的编译参数：

1. 即时编译可实现更大的可移植性。这不是中间格式的原因吗？我的意思是，一旦您将虚拟字节码安装到计算机上，就没有什么可以阻止您将其编译为本机字节码。可移植性是“分发”阶段的问题，而不是“运行”阶段的问题。
2. 好吧，那么在运行时生成代码呢？嗯，这同样适用。没有什么可以阻止您将真正的即时需求的即时编译器集成到您的本机程序中。
3. 但运行时无论如何都会将其编译为本机代码一次，并将生成的可执行文件存储在硬盘驱动器上某处的某种缓存中。好，当然。但它在时间限制下优化了你的程序，并且并没有让程序从此变得更好。请参阅下一段。

这不像提前时间编译也没有任何优势。准时制编译有时间限制：您不能让最终用户在程序启动时永远等待，因此需要在某个地方进行权衡。大多数时候，他们只是优化得较少。我的一个朋友有过侧写证据“手动”内联函数和展开循环（在此过程中混淆源代码）对他的性能产生了积极影响C#数字运算程序；在我这边做同样的事情，和我的C程序完成相同的任务，没有产生积极的结果，我相信这是由于我的编译器被允许进行广泛的转换。

然而我们却被紧张不安的程序所包围。C# and Java无处不在，Python 脚本可以编译为某种字节码，而且我确信许多其他编程语言也会这样做。我失踪一定有充分的理由。那么是什么让及时编译如此优于提前时间汇编？

EDIT为了消除一些混乱，也许重要的是要声明我完全支持可执行文件的中间表示。这有很多优点（实际上，大多数争论及时编译实际上是中间表示的参数）。我的问题是如何将它们编译为本机代码。

大多数运行时（或就此而言的编译器）更喜欢即时或提前编译它们。作为提前时间对我来说，编译看起来是一个更好的选择，因为编译器有更多的时间来执行优化，我想知道为什么 Microsoft、Sun 和所有其他公司都采取相反的方式。我对与分析相关的优化有点怀疑，因为我的经验及时编译的程序显示出较差的基本优化。

我使用 C 代码的示例只是因为我需要一个示例提前时间编译与及时汇编。事实是C代码没有发送到中间表示与情况无关，因为我只需要表明提前时间编译可以立即产生更好的结果。

1. 更大的便携性： 可交付成果（字节码）保留 便携的

2. 同时，更多的平台特定性：因为 JIT 编译发生在 代码运行的系统相同，它 可以非常非常微调 那个特定的系统。如果你这样做 提前编译（并且仍然 想要将同一个包裹运送到 每个人），你必须妥协。

3. 编译器技术的改进可能会产生影响 现有的计划。更好的C 编译器根本帮不了你 已部署程序。 A 更好的 JIT 编译器将改善 现有计划的绩效。 您十年前编写的 Java 代码今天将运行得更快。

4. 适应运行时指标。 JIT 编译器不仅可以查看 代码和目标系统，但是 还包括如何使用代码。它可以 检测正在运行的代码，以及 做出有关如何优化的决定 例如，根据什么 通常对方法参数进行赋值 碰巧有。

你说得对，JIT 会增加启动成本，因此它有时间限制， 而提前编译可能会花费它想要的所有时间。这使得 更适合启动时间不太重要的服务器类型应用程序 在代码变得非常快之前的“预热阶段”是可以接受的。

我想可以将 JIT 编译的结果存储在某个地方，以便下次可以重复使用。这将为您提供第二个程序运行的“提前”编译。也许 Sun 和 Microsoft 的聪明人认为，新的 JIT 已经足够好了，额外的复杂性不值得麻烦。