我最近一直在考虑它，在我看来，赋予JIT编译的大多数优势或多或少应该归因于中间格式，而自动拼合本身并不是生成代码的好方法。
因此，这些是我通常会听到的主要的准JIT编译参数：
- 即时编译可提供更大的可移植性。那不是中间格式吗？我的意思是，一旦在计算机上安装了虚拟字节码，就没有什么可以阻止您将虚拟字节码编译为本地字节码了。可移植性是“分发”阶段的问题，而不是“运行”阶段的问题。
- 好吧，那在运行时生成代码呢？好吧，同样适用。没有什么可以阻止您将真正实时需求的实时编译器集成到本机程序中。
- 但是运行时无论如何只能将其编译为本地代码一次，并将生成的可执行文件存储在硬盘驱动器上的某种缓存中。当然可以。但是它在时间限制下优化了您的程序，并且从那以后并没有使它变得更好。参见下一段。
这也不是说提前编译也没有优势。即时编译具有时间限制：程序启动时，您不能让最终用户永远等待，因此需要在某处进行权衡。大多数情况下，它们的优化程度较低。我的一个朋友提供了剖析证据，表明内联函数和“手动”展开循环（混淆过程中的源代码）对其C＃数字运算程序的性能产生了积极影响。在我这边做同样的事情，我的C程序执行相同的任务，没有产生积极的结果，我相信这是由于允许编译器进行的广泛转换。
但是，我们仍然被固定程序所包围。C＃和Java无处不在，Python脚本可以编译为某种字节码，而且我敢肯定，还有很多其他编程语言都可以做到这一点。我想必一定有一个很好的理由。那么，什么使即时编译比提前编译好呢？
编辑为了消除一些混乱，也许重要的是要声明我全都是可执行文件的中间表示。这具有很多优点（实际上，大多数实时编译参数实际上是中间表示的参数）。我的问题是关于如何将它们编译为本地代码。
大多数运行时（或与此相关的编译器）宁愿及时或提前编译它们。由于提前编译对于我来说似乎是一个更好的选择，因为编译器有更多时间执行优化，所以我想知道为什么Microsoft，Sun和所有其他公司都朝着相反的方向发展。我对与概要分析相关的优化有些怀疑，因为我对即时编译程序的经验显示出较差的基本优化。
我用了一个例子与C语言代码，只是因为我需要的例子名列前茅的时间编制与刚刚在时间编译。C代码没有发出到中间表示的事实与情况无关，因为我只需要证明提前编译可以产生更好的即时结果。