[Nightly] Firefox 23.0a 添加新的基准线编译器

老实说，对于 JS 编译这块我不是太懂，本身没有任何编译版本的经验，所以所有的介绍都是抛砖引玉，有错误指正一下，不要喷哈。

请先看 Mozilla 官方博客的技术介绍文章：The Baseline Compiler Has Landed

Firefox Nightly 加入了新的基准线编译器（Baseline Compiler），之前 pcxfirefox 贴图所指出的 BC 就是 Baseline Compiler。有了它，可以继续极高编译速度，提升 JS 性能。

按官方说法，加入后，在自家的 kraken 基准测试和 Google 的 octane 测试中，性能有 5%～10%的提升。



Firefox 的实时编译器有两个：JaegerMonkey 和 IonMonkey，前者是初级，后者是高级，代码先放在  J 当中编译，然后放到 I 编译，耗时且量大，这个新的 BC 取得了平衡，因而提高了性能。

长期来说，这个 BC 将代替 JaegerMonkey，成为 IonMonkey 编译器的基准线编译器。按 Mozilla 的方式，应该是高级别的编译器需要有一个基准线编译器，以前是 J，今后将变为这个 BC。

那对于我们普通用户来说有和好处呢？简单说就是感受到网页加载性能提升、高级功能体验更好（比如大型网页游戏）、占用内存继续下降。

pcxfirefox：另外，我目前也对pgo优化持反对态度，虽然pgo是提升效能最简单也是最大的武器。
20以来，我减少了90%以上的pgo测试来达到和full pgo相差不大的效果，也是针对pgo时间过长的方法，幸好vc有pgomerge的分析工具，可以对pgo测试的增减影响进行分析，所以效能损失也不是很大。

除PGO等唯武器论方法外，也就是源码的根本提升了，虽然这是由Mozilla方面推动的，不过还有很大潜力可挖。当然，唯武器论的另一个高级方法就是换其他编译器进行构建了，只要你有找一堆bug的时间，本来我是想交给Waterfox和Cyberfox方面实践的，可是他们构建的都不甚令人满意，期望有其他人加入竞争。回到原帖

这么说来，那还是算了，pgo的确费时

另外，我目前也对pgo优化持反对态度，虽然pgo是提升效能最简单也是最大的武器。
20以来，我减少了90%以上的pgo测试来达到和full pgo相差不大的效果，也是针对pgo时间过长的方法，幸好vc有pgomerge的分析工具，可以对pgo测试的增减影响进行分析，所以效能损失也不是很大。

除PGO等唯武器论方法外，也就是源码的根本提升了，虽然这是由Mozilla方面推动的，不过还有很大潜力可挖。当然，唯武器论的另一个高级方法就是换其他编译器进行构建了，只要你有找一堆bug的时间，本来我是想交给Waterfox和Cyberfox方面实践的，可是他们构建的都不甚令人满意，期望有其他人加入竞争。

teredarguitereprodlo：

vs2012的pgo效果不大（很多个都是pgo优化的），vs2010太费时回到原帖

不过我有vc2012 pgo提升到vc2010的work around方法，只是不太稳定
我需要准备一些资料反馈到微软和他们开发者讨论，不过Ankit Asthana（VC编译器后端优化开发者）总是不理我，N多邮件不回复我

不然你教教teredarguitereprodlo怎么弄pgo，嘿嘿

vs2012的pgo效果不大（很多个都是pgo优化的），vs2010太费时

等Release吧

vc的pgo太费时了

不然你教教teredarguitereprodlo怎么弄pgo，嘿嘿

bingyuan：
兄台要不来个23.0a的pgo版本，嘿嘿回到原帖

等Release吧

vc的pgo太费时了

最近我在看arewefastyet的架构，确定这里面的测试都是去除了PGO的影响，因为这个是测试的js shell的成绩，而不是浏览器运行的测试。Mozilla的js shell也没有进行PGO优化。

兄台要不来个23.0a的pgo版本，嘿嘿

PGO 应该是包括的。

最近我在看arewefastyet的架构，确定这里面的测试都是去除了PGO的影响，因为这个是测试的js shell的成绩，而不是浏览器运行的测试。Mozilla的js shell也没有进行PGO优化。

这样的话似乎也去掉了PGO对性能提升的影响

PGO 应该是包括的。

nighttalker：
那不是任何一个fx的版本，那是js引擎裹在一个外壳里。awfy的唯一目的是让写代码的能够看到他们代码的效果。

我估计latest-ionmonkey是现在离那些数据最近的可运行版本 ftp://ftp.mozilla.org/pub/firefox/night ... ionmonkey/回到原帖

这样的话似乎也去掉了PGO对性能提升的影响

rasis：
arewefastyet 上面ff用的是哪个版本？？回到原帖

那不是任何一个fx的版本，那是js引擎裹在一个外壳里。awfy的唯一目的是让写代码的能够看到他们代码的效果。

我估计latest-ionmonkey是现在离那些数据最近的可运行版本 ftp://ftp.mozilla.org/pub/firefox/night ... ionmonkey/

由于BC enable时， JM不编译任何东西，可能会在24时去掉JM也说不准

感谢楼上各位大佬的悉心解答！
难怪现在js的执行效率都逼近native code了，原来有这么多复杂的优化技术，看来浏览器上的js已经不能成为完全的动态语言了……从runtime的角度来看好似是混合编译的呢

nighttalker：
https://blog.mozilla.org/javascript/201 ... as-landed/
Mozilla 的 js 引擎是spidermonkey， 其中有几个不同的组件。JaegerMonkey, Ionmonkey, Type Interface.

Spidermonkey本身是一个翻译器，由于最后的结果不是机器代码，速度比较慢。Jaegermonkey/ionmonkey/baseline compiler都是动态翻译器，作用都是把某些js代码转成机器代码。

现在mozilla用的动态翻译器是jaeger/Ion，baseline compiler 会替代 jaegermonkey。这个计划有很多优势，因为baseline compiler和ion合作更好，提供更多的type-interface信息，使用更少的内存。回到原帖

arewefastyet 上面ff用的是哪个版本？？