dongyuanxun：因为没时间
如果有额外的机器做编译服务器还有可能
这样就算是每小时版也能编译着玩回到原帖

优化Nightly也不是说真的要一天一编。。只要一周或两周一更新就行了，而且相对而言不会被官方发布时间不规律的小bug修正版（比如x.0.1这种）牵着走。重要的是能利用上最新的特性，FF9的新的JS解释器，FF11的SPDY。。这些如果用上带来的性能提升就已经超过调编译参数所能达到的了

時間啊...
我編譯FX 8.0.1，一次編譯要花93分鐘的時間
然後再花30～45分鐘的時間進行調教
然後二次編譯要花154分鐘的時間
運氣好或許編譯不會失敗

像我今天編9.0b3，在調教的過程中就發生三次崩潰...
綾川跟tete009的機器性能我想應該非常好
我曾經看過tete009在一天之內
數小時的時間一日兩編
而這兩編的時間間隔甚至比我只編譯一次還要短..

綾川就更不用說了，有支援AVX的CPU至少都是Core i等級的
我的只是Q6600老Quad Core，性能遠遠不如，就不強求了

刚看到Lawliet的9.0b3了，体验中。。。

现在在用ayakawa 11a1编译版，感觉很好，比8,9明显要快。

建议Lawliet也做一个11.0a1每夜版的，
不用太频繁就和ayakawa那样半个月左右更新一次就好了。

Lawliet：時間啊...
我編譯FX 8.0.1，一次編譯要花93分鐘的時間
然後再花30～45分鐘的時間進行調教
然後二次編譯要花154分鐘的時間
運氣好或許編譯不會失敗

像我今天編9.0b3，在調教的過程中就發生三次崩潰...
綾川跟tete009的機器性能我想應該非常好
我曾經看過tete009在一天之內
數小時的時間一日兩編
而這兩編的時間間隔甚至比我只編譯一次還要短..

綾川就更不用說了，有支援AVX的CPU至少都是Core i等級的
我的只是Q6600老Quad Core，性能遠遠不如，就不強求了回到原帖

我知道编译FF非常耗时间，特别是开PGO来编。我的本意只是建议你们或你们中的一个放弃官方稳定版，直接只编译维护Nightly版本。

因为作为使用第三方编译版FF的用户而言，应该大多是比较喜欢追新feature和高性能，不那么care稳定性的（我以我自己为例来推测别人了，不知道是不是事实:p）。

无论怎么样，感谢你们的努力以及无私的分享。pcx提出多测试pgo以及lawliet用常浏览网站作为测试源都是很好的想法。

我的还是Core2呢，所以我期望Firefox的版本越少越好，时间出的越久越好

我还是会兼顾到js测试，不过在之后的版本中我想要引入更多的feature，比如升级一下zlib/png/sqlite3/jpeg/freetype2等库。
特别是zlib/png/sqlite3新版本/开发版本的速度特性比较突出，应该对经常浏览开源网站（gcc/bugzilla/svn/git）的人有很大帮助。cario升级太麻烦，libffi也可能升一下，angleproject还没决定升（对WebGL有用），Media那些先放一放。

其他可供升级的组件我不清楚，如果大家知道哪个组件升级潜力比较大，可以PM我或者在Google Code上写issue。

其實真要編譯Nightly其實也行
但最多就一星期一編
主要還是以release版為主

我今天編FX 9.0b3之前
發現有一些patch不能用了
花了點時間自己diff跟驗證
不像先前直接網上抓patch打上就好
我可能要等到換了機器，也許換AMD最新的8CORE？
只是不曉得編譯性能上跟intel的4Core8Thread哪個比較好

Lawliet：其實真要編譯Nightly其實也行
但最多就一星期一編
主要還是以release版為主

我今天編FX 9.0b3之前
發現有一些patch不能用了
花了點時間自己diff跟驗證
不像先前直接網上抓patch打上就好
我可能要等到換了機器，也許換AMD最新的8CORE？
只是不曉得編譯性能上跟intel的4Core8Thread哪個比較好回到原帖

FYI: <!-- w --><a class="postlink" href="http://www.ixbt.com/cpu/results/results-2011.xls">www.ixbt.com/cpu/results/results-2011.xls</a><!-- w -->
第40行MSVC，你可以比较下FX8150和I7 2600的分数

一星期一编就很足够了，甚至一个月一编都行。我相信虽然Nightly天天更新，真的很大影响到性能的更新也不会很频繁；但如果拿Nightly和正式版比提升就不小了。

dongyuanxun：我的还是Core2呢，所以我期望Firefox的版本越少越好，时间出的越久越好

我还是会兼顾到js测试，不过在之后的版本中我想要引入更多的feature，比如升级一下zlib/png/sqlite3/jpeg/freetype2等库。
特别是zlib/png/sqlite3新版本/开发版本的速度特性比较突出，应该对经常浏览开源网站（gcc/bugzilla/svn/git）的人有很大帮助。cario升级太麻烦，libffi也可能升一下，angleproject还没决定升（对WebGL有用），Media那些先放一放。

其他可供升级的组件我不清楚，如果大家知道哪个组件升级潜力比较大，可以PM我或者在Google Code上写issue。回到原帖

这个方向也很好，不过测试过程可能比较艰辛，不知道会不会有未知兼容问题。也许FF主程序还稳定，结果某些扩展就挂了。我觉得这是个挺难的任务，但一旦做成了贡献远比这些调编译参数大。过两个礼拜放假了有时间我也想尝试看看有没有能patch的地方。我的问题也是电脑太次。高性能机器是有，但都是Linux。。

png1.5.x移植太麻烦，准备放弃
这个弄得libpr0n里里外外都要改
几十个宏……

早上編譯了Nihtly版
總編譯時間比8.0.1多了一個鐘頭的時間
卻因為PGO bug導致失敗....
就9.0b3跟今天這個Nightly的情況來看
我之後能在Firefox上做的優化會越來越少
好多問題要解決，不如原本的自動PGO編譯那樣方便

我暂时测试的子项目升级情况
Update libjpeg to latest svn trunk (Test Passed)

Update FreeType 2.4.3 to 2.4.8 (Test Passed)

Update zlib 1.2.5 to git develop (Test Passed)

Update bzip2 1.0.4 to 1.0.6 (Test Passed)

Update sqlite 3.7.7.1 to 3.7.9 (Test Passed)

Update ots svn r62 to latest (Test Passed)

Update ANGLE project svn r740 to latest (Test Passed)

Update libpng 1.4.x to 1.5.x (Test Failed )

應該有libjpeg-turbo就好了
libpng貌似沒有對SIMD有任何加速作用

有些也不一定非得需要SIMD，看内部的算法
libpng1.5.x的interlaced PNG比libpng1.4.x的性能高5%-10%，但是移植太麻烦
zlib的git比zlib1.2.5的速度略高（64位更明显些）
bzip2的新版本主要解决了一个安全性因素
sqlite3.7.9的遍历数据库效能要高些
以上我其他代码里在用，所以清楚一些

freetype和渲染有关，速度不清楚
ots也不了解
angle和webgl/硬件加速有关
这三个只是简单升级了下，不知道对速度有什么影响

flash部份能優化嗎？
昨天有人說waterfox的flash性能明顯超過我的, 您的, tete009, 綾川
我用我自己的去跑了一下，還確實如此
http://kyokojap.sg1006.myweb.hinet.net/dogs/

不曉得這部份跟原生64bit有沒有關係？

64bit插件和32bit插件本来性能就有差异

这个得问Adobe