两种JavaScript解析引擎性能对比谈-javascript解析引擎

随着Google Chrome的发布，Web应该说是老树发新芽，在技术本身并没有突破的情况下，每一个环节都在以更快的速度进行前进，譬如：

◆JavaScript。现在每一个浏览器都在比较谁的执行速度更快，在你追我赶的过程中，毫无疑问，Web变得更加快速，应用的能力也有越来越强大了。IE6、FF2的时代在现在回顾起来，已经变成老牛拉车的"历史"了。

◆Web标准化的速度也越来越快，CSS、HTML 5的普及越来越加速，手机也从WAP快速的向Web标准看齐。原来更多的Web开发向IE倾斜的趋势，现在更多的向标准化倾斜。

◆与Flash的争斗，尤其是apple的旗帜鲜明的不支持Flash，特别是在已经开始预售的iPad上摒弃了Flash，促使HTML 5的职能从传统的文字图片迅猛的向2D、动画、视频等领域扩展，将对Flash这样的私有技术构成威胁。（51CTO编者注：近日Adobe高管曾回应说，“HTML 5要想追上Flash，还要一段不短的时间；而且，也有可能永远追不上”）

所有的这些，都意味着Web正在朝着第2春进行努力。本文则试图收集一下目前各主流浏览器的JavaScript加速机制，尝试探讨未来JavaScript能走多远？

Firefox 3.6 Trace JIT 技术

Firefox在Chrome的压力之下，迅速的发布了TraceMonkey引擎，这个技术的特点是：

1、JS解释器首先将源代码转变成为JavaScript字节码（LIR），每一个字节码都是SSA（Static Single Assignment）的。这个字节码在某种格式上与Java Bytecode是类似的。不同的是，JavaScript字节码缺乏类型信息，因此，在解释的过程中，需要根据当前的数据，进行选择性的处理。因此，每条指令其实都是涉及到更为复杂的运行时类型检查、动态分派的。

2、TraceMonkey首先以解释的模式运行指令，但对loop（向后跳转）进行特殊关注：每一个向后跳转指令意味着一次循环的开始，TraceJIT关注的是对循环的优化，当一次循环开始时，TraceMoney试图对一次循环的所有指令进行跟踪，拉出一条平坦的执行线索(trace tree）。

3、每一条执行线索，对其内部的类型信息，已经进行了一个假设，在这条线索执行过程中，相关的字节码实际上可以理解为已经替换为类型化的字节码（类似于Java的Bytecode）了。这个类型化的字节码再经过简单的JIT编译后，直接以机器码的方式执行。在线索执行开始时，会对类型信息进行检查，如果出现类型不匹配，则可能产生一个新的执行线索。

4、执行线索内在的包含了method inline等技术。

应该说，这种Trace技术，与以往的method level JIT相比，是完全不同的。在适合的应用里，Trace JIT相比V8等，还会有更大的执行效率提高。

Chrome V8毫无疑问是本次浏览器大战的导火索，其功过还需要时间来验证。V8的优化机制：

◆Fast Property Access。快速对象属性访问。其特点是将JS对对象属性的访问，从一个动态的查找过程转换成类似于Java/C++的静态访问。毫无疑问，在JavaScript中，对象属性访问是最为频繁的一类操作，这个动态查找的过程其实是相当之消耗时间的。

◆动态机器码生成。这个也是与快速属性访问相关的。它把动态的JS对象转变为一个类似于Java的静态布局对象。

◆有效的GC。V8提供的是一个stop-the-world, generational, accurate的GC机制。而FF提供的则不是一个分代的GC。在实际应用中，分代的GC相比不分代的GC显然具有更高的效率。这一点，也是Java Hotspot所必须的。

其它的，Opera 10.50号称推出了世界上那个最快速的JS引擎，不过，由于没有文档资料，暂时并不清楚其内部机制。

预测：

FF的优化机制和V8的优化机制是不一样的，两者完全是可以互补的。因此，可以想象，如果将V8的优化机制，如快速对象属性访问、分代GC等引入进来，结合Trace JIT技术，相信速度会有更大的提升。同理，对于V8而言，如果将Trace技术引入进来，对运行时的类型进行更准确的预测，那么，执行速度应该也有更大幅度的提升。

综上，这些优化技术赋予了JavaScript更为强大的处理能力，使得浏览器可以更为快速的"下载执行"更大型的应用。使得原本需要在"native"语言中完成的功能，现在开始，可以在脚本语言中支持。

【编辑推荐】