Compiler construction 是否有类似“的东西？”；编译时JIT；？

据我所知，JIT（即时编译）指的是一个运行时进程，其中字节码被编译（翻译）为本机代码以提高运行时性能

另一方面，编译时评估是通用编程或运行时优化的常见做法。同样，据我所知，在本例中，编译器解释源代码以计算表达式（例如生成值或类型）。在这种情况下，编译时间通常会显著增加

是否存在编译器将源代码翻译为本机代码以进行更有效的编译时评估的编译时JIT过程？我觉得这很自然，但是有任何编译器在任何语言中都这样做吗

---

如果我在自己的编译器中这样做，这是个好主意吗？与运行时JIT相比，我还有什么额外的困难？

没有任何意义。编译器已在编译代码。常量表达式求值只发生一次。例如，Java HotSpot JVM只发现在执行了数千次之后才将方法编译为本机代码是有益的。

我认为您所说的——当默认行为是解释或即时代码生成时，提前执行代码生成——被称为

好处：

• 如果读取本机映像比翻译通常较小的中间语言映像快，则启动延迟较低
• 一个进程的多个实例之间的已翻译本机代码共享页可能会减少主内存占用，但仅当多个实例同时运行时

缺点：

• 更难根据运行时特征进行优化；HotSpot的动态概要文件导向的整个程序优化可能会在不同的程序中以不同的方式编译相同的方法，具体取决于它的使用方式
• 由于本机映像通常比中间代码大，并且在生成本机映像后通常无法删除中间代码，因此总的程序存储占用空间通常会增加

---

可以想象，您可以在AOT编译的代码上进行基于概要文件的整个程序优化，但最终会得到类似于HotSpot运行时的“预热”版本的东西，在足够热的方法上交换共享内存，从而值得重新编译它们的翻译。

您的意思是提前将字节码编译为本机代码吗？如果是这样的话，互联网上有很多这样的程序。因为“编译时JIT”毫无意义。“编译时”是“在用户运行它之前”，“JIT”是“在用户开始运行它之后”。不可能真的有混合动力车。编译在用户启动代码之前或之后进行。哦，等等，你是说编译器在哪里生成本机代码，然后在静态编译期间执行本机代码？我希望C++ +CODEX> CONTXPRP<代码>正好适用于这个概念，尽管我怀疑C++中的其他东西。C++中的常数和类型的编译时评估通常不执行“代码”，就像“在表中查找数据”一样。（我做C++很明显，不能和其他语言一样）“哦，我是说你在第二个评论里说的。”C++ >代码> CONTXPRPR <代码>在编译时做所有的评估，但我不知道如何。我读到D是通过解释代码来实现的，这比运行本机代码慢1-2个数量级。仅仅测量编译时间（CLAN或特别是GCC），我认为C++在实践中没有任何更好的地方。Jeffrey Hantin，你能说出一些AOTS，比如在最新的4.4个Android中，对于java？…@ OSGX，我在CLR的土地上已经这么长时间了，所有这些都被想到了。谢谢指针，但这不是我的意思。我的意思是，编译器看到一个可以在编译时计算的表达式，比如

fibonacci（15）

；它编译

fibonacci

，为它生成本机代码；它调用此函数并计算结果；它将结果作为常量插入，替换表达式；它正常编译其余代码，生成本机代码或中间代码或其他任何代码；在运行时，此表达式根本不需要计算。我希望这更清楚。@iavr哦！那在和之间。持续折叠只是一个可能属于部分评估范围的优化。@JeffreyHantin确切地说，对不起，我认为也很清楚。总之，我知道这种情况至少在C++（）中是经常发生的，它只是编译速度太慢，因此我的问题。在源代码的每一次更改中，只有一次发生稳定表达式计算。也就是说，取决于你试图编码的代码，它可能每分钟发生一次，持续30秒。C++允许你编写编译过程中编译器执行的函数，我认为这是他所指的，如果那些被解释或编译，然后执行。像

lex

和

yacc

这样的工具可以预先计算输入语法的标记化和解析表，这可以被看作是一种计算形式。在一般情况下，使其对程序员透明需要部分评估。