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