FF 的 TraceMonkey 加速 JavaScript
对不住，仍然是 JavaScript 的消息， 并不是我存心要改行播报 JavaScript 新闻，而是这条实在太重磅，不报不合适了都。
刚刚还在[上一篇]的回复中数落 FireFox 不务正业地搞什么“多脚本语言支持”，而不去专心加速 JavaScript 的运行。貌似这句话现在我就得自己吞回去了。因为 John Resig 同学博了一篇关于 FireFox v3.1 之中的 TraceMonkey 技术，加速约7倍！这一消息表明 FireFox 内部在 JavaScript 上的投资仍然保持了足够的“密度”。
TraceMonkey 基于 trace tree 理论。是一种 JIT [Just In Time] 优化技术。简单地说，JIT 就是在“合适的时候”（也就是 Just In Time 的要义）将 JavaScript 编译为 native code 再来执行（Java 很早就已经采用 JIT 来提升性能了）。而 trace tree 则对这些 native code 再做进一步的化，比如：优化函数调用，优化类型检测，优化循环，等等。据称，在多项性能测试之中，开启了这一特性之后，脚本的运行性能有了“惊人的”提升。有图为证：
而，这一特性在 nightly build 的 FireFox v3.1 中已经就绪，只需下载，安装，并在 about:config 中打开选项：
- javascript.options.jit.content = true
即可立即开始体验。
顺便八卦一句：FireFox v3.1 的脚本引擎仍然还是 SpiderMonkey，TaceMonkey 只是 SpiderMonkey 的一个版本代号，它有很多代码都是来自于 Adobe 捐赠的 Tamarin 引擎，看来这只猴子的消化力的确很强。
另外八卦一句：打了鸡血的 SpiderMonkey 已经显著超越了 SquirrelFish 的性能。
对JS世界是超好的事，JS的速度将可以进一步的迈进compiled code了
js性能提升大有好处。
恩，采用js来做页面，erlang的mochiweb做本地http server，来实现交互好的应用程序很不错哦。或者air + erlang来实现？
综合的性能测试在这里：
http://ejohn.org/blog/javascript-performance-rundown/
各有各的特长，目前 V8 的递归性能目前还是最好的，看来 TraceMonkey、SquirrelFish 以及 V8 将会展开一场精彩的竞速厮杀。
没事无聊在linux上面编译了v8和tracemonkey两个引擎，跑了一下language shootout上面的代码，对 fasta，100w loops
time ../v8shell fasta.js > /dev/null
real 0m11.572s
user 0m11.569s
sys 0m0.004s
time ../js -j fasta.js > /dev/null
real 0m17.536s
user 0m17.397s
sys 0m0.140s
而 partialsums 呢，100w loops：
time ../js -j partialsums_v8.js
3.000000000 (2/3)^k
1998.540145491 k^-0.5
0.999999000 1/k(k+1)
30.314539402 Flint Hills
42.995233566 Cookson Hills
14.392726723 Harmonic
1.644933067 Riemann Zeta
0.693146681 Alternating Harmonic
0.785397913 Gregory
real 0m1.078s
user 0m1.076s
sys 0m0.000s
time ../v8shell partialsums_v8.js
3.000000000 (2/3)^k
1998.540145491 k^-0.5
0.999999000 1/k(k+1)
30.314539402 Flint Hills
42.995233566 Cookson Hills
14.392726723 Harmonic
1.644933067 Riemann Zeta
0.693146681 Alternating Harmonic
0.785397913 Gregory
real 0m2.109s
user 0m2.100s
sys 0m0.008s
两者性能都各有偏重，但相比Lua来说速度还是慢了些，以后或许这些VM能达到LuaJIT的高度？拭目以待