JIT 为什么比 interpretation 快呢？

JIT会编译部分代码，并对反复用到的代码段进行优化

@chengdujin 我的问题是，这种优化不能在解释器中使用吗？

@shyrock jit和解释执行不矛盾吧？jit版本一样也是解释执行吧？
我的理解是，加上jit会和平台相关，所以jit一般都是另外去做，而不会放在一个语言的官方发布版本里面

JIT编译后基本可以做到每个运算都有与之对应的机器码，而解释执行的话会有很多指令周期花在解释翻译上。当然编译也是要花时间的，所以不是什么代码都JIT的，像 mozilla js、v8等等都是分级的，越热的代码越一次花大量的时间编译优化，不热的代码就解释执行，这样可以做到启动和执行效率多不错。

@clino 如果说jit的优势是根据运行期平台做特性优化，那么解释器为什么不能做呢？

@heiher 如果说jit是执行快，但是牺牲了启动时间的话，似乎可以解释得通。那按这么说，只执行一次的话，jit比解释要慢？

@shyrock 当然可以做啊，为什么不能做，只是这样做出来的解释器只能在某个平台上用，那如果有n个平台就要维护n份解释器，这个需要用钱去堆出来的吧

@clino 成本是另一回事，如果你说的是‘不管成本的话，解释器和JIT能做到相当的性能’，那我就明白了。

而且jit解释器可能会比不带jit的解释器bug更多，所以一般来说jit解释器出问题了可以找官方非jit解释器做对比，这样能知道是否是jit引入的，但如果都是jit可能就不好这样排除问题了

@shyrock 应该说带jit的解释器和不带jit的解释器吧
我的理解是不带jit的是解释翻译成字节码然后字节码在虚拟机里运行
带jit的解释器是直接解释翻译成机器码执行

JIT 不一定比解析快 但是如果是CPU繁重的工作 那肯定是JIT会更快
JIT 本来就是要在 编译+执行 还是 解析执行 之间进行权衡
由于动态脚本编译时类型推测和优化都很费时间 而且有可能编译后效果仍然不理想
所以在做大量优化和调试前 很多JIT开发初期 可能都比成熟的解析器要慢


@shyrock 对于只执行一次 也不一定时谁快 如果使用了大量的动态特性 或者只是简单的执行一些指令那么解析执行可能会更占优势 但是如果有CPU繁重的工作 比如很多循环和计算 那么编译后执行会快

不过我觉得现在还是AOT比较好 发布的时候可以预编译成字节码 然后下载安装的时候 编译成本地代码执行

@yyfearth 感觉有些明白了，谢谢。

解释器是解释执行的，一个表达式出来，解释器总是去先做字符串处理。如果是有字节码，也是先去分析字节码代表的含义，然后按照这个命令执行，距离机器更远一些。一条简单的加法指令，在解释器内可能要经过多条指令，而且每次遇到这个表达式需要这么多指令。

JIT 是每次运行到一个表达式之后，就把他编译成机器码，放在内存中，下次遇到这个表达式，直接把机器码送入CPU。一条简单的加法指令除第一次需要编译之外，之后就跟机器码的加法运算没什么大的差别。所以速度更快。

但是问题是 JIT 编译需要的时间比解释器长，代码运行的时间要比解释器更短。带 JIT 的编译器实现更复杂，维护成本更高。所以很多编程语言都要做 TradeOff。

那为什么要 JIT 而不是直接集中编译运行呢。首先，集中编译本身需要的时间就比较多，跨平台比较麻烦。如果想用一个二进制文件在多个平台上都可以跑很不方便，要分别编译然后打包在一起，导致可执行文件很臃肿。此外，JIT因为可以访问运行时环境，有些时候能做出比静态编译更好的优化。

所以总体来说 JIT 可以看做介于解释运行和编译运行之间的一种技术，是一种性能和跨平台能力之间的平衡。

另外，JIT 本身可以认为就是对单纯的解释器做出的优化。只集中编译热点代码也是考虑到JIT第一次编译需要一定的时间。当然现在还有 ART 技术，就是在安装程序的时候集中编译。

@ant_sz 很完整很清晰，谢谢。

还有一种情况，有些优化和执行的次数/频率有关，比如弱类型语言的类型推测，如果只运行一次，那做推测完全是多余的活，还不能保证第2次类型没变。但一段代码运行了1000次一个对象类型没变化过，那做一次类型推测后面再运行2000次就有收益

@otakustay 是这个意思。