Andreas Gal 讲述了TraceMonkey的基准参数:

TraceMonkey是一个基于跟踪的即时编译器，对JavaScitps性能有大幅度的提高。平均来讲，按照苹果公司流行的SunSpider基准，新版本Firefox性能超过上一个版本4.6倍。总的运行性能比SunSpider基准提高了1.83倍（SunSpider的某些测试，例如正则表达式引擎不在即时编译范围内，因此整体性能提高不是很多）。对于SunSpider中专注于核心JavaScript语言引擎的ubench基准，我们提高了22倍。无论你采用何种方式度量，Firefox目前都拥有世界上最快的JavaScript引擎。

我们的即时编译器产生的代码性能接近于未优化的C语言代码（gcc -O0）。

同时，他也解释了跟踪机制是如何起作用的：

传统的即时编译器（例如Sun的Hotspot虚拟机）在设计和结构上非常类似于静态编译器（例如GCC）。这种编译器会监控程序中哪些方法执行比较频繁，一旦达到某个阈值就把这些方法翻译成原生机器代码。虽然这些方法通常包含了影响关键性能的代码（例如循环），但是它们经常也会包含“慢腾腾”的路径和非循环代码，而这些对方法的运行性能几乎没有任何影响。但是，这样一个针对完整方法（while method）的编译器不得不分析和编译整个方法，即使该方法的某些部分不值得去“特别照顾”。基于跟踪的编译器则采用一种完全不用的方式。我们通过虚拟机监控字节码的解释过程，同时扫描频繁调用的向后（backwards）分支，这些分支在程序中意味着循环。一旦我们确定了循环的起始点，我们跟着解释器执行程序并记录字节码指令的顺序。因为我们记录了循环的起始点，解释器一旦执行完一次循环最终会返回起始点。这个被记录下的线性指令顺序我们称之为跟踪。

跟踪代表了循环的单次执行，可以跨方法和程序模块。如果在循环中调用一个函数，我们会展开这个函数调用，把函数的代码内嵌到循环中。这样函数调用就不再需要记录了。我们只是在运行时确认调用该函数的条件是否成立即可。

Mike Shaver也提到了针对Firefox JavaScript Engine所作的工作：

在过去的一年中，JavaScrip在Web上的性能得到了显著的提高。几乎每一个浏览器都在改善它们的引擎以获得执行速度上的提高。比如，Firefox 3比Firefox 2在各种测试基准上都快大约3倍。当然，开发人员和用户对性能的需求是无止境的，为Mozilla工作时，我们自己也有性能需求，因为我们在很大程度上是用JavaScript写程序。除了提高Web应用的性能，我们针对TraceMonkey所作的工作也让我们自己的程序更快更灵活。

Brendan Eich在博客里提到了这些性能提升的意义：

抛开细节，这里列举一些重点：

• 目前，TraceMonkey支持x86、x86-64和ARM。这意味着我们已经为移动和桌面平台做好了准备。
• 随着性能持续提高，人们会把“很慢”的代码转化成JavaScript在浏览器中运行。这意味着Web未来能够承受那些现在需要配置专有插件才能完成的运行压力。
  

• 随着跟踪更多DOM和其他原生代码，我们提高了代码的内存安全水平，保证不会含有能够被利用的bug。
• 跟踪机制只关注关键路径，建立跟踪树缓存。非关键代码绝不会被跟踪或即时编译，避免完整方法编译器带来的内存膨胀。跟踪机制很灵活。

• JS驱动的 JS驱动的显示，包括工具包、图片、游戏逻辑等等，都在JS中实现，将是未来的趋势。

TraceMonkey让我们向Mozilla 2更进一步，更多的代码由JS写成。Firefox随着这些发展会变得更快和更安全。

John Resig也谈到了这些显著的进步对JavaScript语言和RIA未来的意义：

那么，TraceMonkey对我们到底意味着什么？它意味着JavaScript不在受之前处理能力的限制。凭借TraceMonkey，它已经有了巨大的飞跃，可以与强大的计算语言（如c语言）媲美。

我非常希望看到更多和更大的项目采用JavaScript语言。关注性能的项目也能够如偿所愿，例如涉及大量数字计算方面（如图片处理）或者大量对象方面（如关系对象结构）的应用。

我特别激动的一点是与Cavans的关系。阻挡Canvas开发的主要障碍不再是显示—而是语言的处理能力限制（执行与矢量、矩阵或碰撞检测有关的数据运算）。我希望这个问题在Firefox 3.1发布后能够解决。

能够看到TraceMonkey即将发布让我非常兴奋。JavaScript绝对是那种能够不断发现缺点却持续取得进步的“小”语言。我希望在未来的许多年中一直使用它。