今天升级到b5pre，成绩差不多；

没啥感觉

ybbao：

我测试每小时版，也只是达到630，比之前B4的660快了点，不知LZ用什么版，能有500多的数值回到原帖

不是我测的，是官方测的，此数据和浏览器本身以及所用电脑的软硬件环境有关。
并且用的也不是一般的小时版，而是JägerMonkey版。

gchao：感觉没必要这样宣传，说实话除了启动速度，其他的啥测速在浏览过程中没感觉到啥区别，关键还是用起来是否感觉顺手，这点FF还是有一定优势的。回到原帖

宣传离不开媒体，而媒体最常挂在嘴边的就是跑分，既然改变不了媒体，那就只能去适应甚至迎合他。何况js性能也是衡量浏览器性能的最重要指标之一，回避不了的

4.0b5pre 0818和JägerMonkey 0818的同机对比

这人这样说难道是Firefox还有什么后着没用？我只期望正式版发布出来的时候JS性能别落后太多就行了。

本人上次测试的jm测试成绩

目前JM稳定在455-465之间


http://www2.webkit.org/perf/sunspider-0 ... sults.html?{%223d-cube%22:[19,19,19,19,18],%223d-morph%22:[18,17,17,17,18],%223d-raytrace%22:[23,23,23,22,23],%22access-binary-trees%22:[21,20,20,20,20],%22access-fannkuch%22:[20,19,20,20,19],%22access-nbody%22:[13,13,13,13,13],%22access-nsieve%22:[8,8,8,8,8],%22bitops-3bit-bits-in-byte%22:[6,5,6,7,6],%22bitops-bits-in-byte%22:[12,11,12,10,11],%22bitops-bitwise-and%22:[5,5,4,5,5],%22bitops-nsieve-bits%22:[8,7,8,7,8],%22controlflow-recursive%22:[11,11,10,10,10],%22crypto-aes%22:[14,14,16,17,14],%22crypto-md5%22:[9,9,9,8,9],%22crypto-sha1%22:[7,6,7,7,6],%22date-format-tofte%22:[29,29,30,29,29],%22date-format-xparb%22:[27,26,22,31,28],%22math-cordic%22:[11,11,11,11,11],%22math-partial-sums%22:[20,20,20,20,20],%22math-spectral-norm%22:[10,11,10,10,10],%22regexp-dna%22:[40,37,40,39,40],%22string-base64%22:[13,13,12,12,12],%22string-fasta%22:[18,18,17,18,18],%22string-tagcloud%22:[44,44,45,44,45],%22string-unpack-code%22:[43,42,41,43,42],%22string-validate-input%22:[16,16,16,17,17]}

装几个扩展影响速度小一点就安乐了。。。。。。引擎拼死拼活抢回来的0.几秒装几个扩展就无效化了，我说，每个扩展才那么几十k到百来k，启动就多花10几秒是不是太过分了一点？

一直觉得傲游的插件机制和默认配置很合理，可惜是IE核心的

dindog：装几个扩展影响速度小一点就安乐了。。。。。。引擎拼死拼活抢回来的0.几秒装几个扩展就无效化了，我说，每个扩展才那么几十k到百来k，启动就多花10几秒是不是太过分了一点？

一直觉得傲游的插件机制和默认配置很合理，可惜是IE核心的回到原帖

要算时间账的话，一个好的扩展可以给你省下来的时间，又岂是它增加的启动时间能比。

使用过好几次chrome，基本上每次用不了多久就放弃了，没有firefox使得顺手

ff本来不觉得臃肿，但是chrome的出现让大家把精力重新聚焦到浏览器本身，也许看报纸就是为了内容明确简洁明了而不是给报纸加上遥控器之类的功能。在回归本质后ff就有点臃肿了。还有一点就是google能够捕捉到现在宽屏显示器被强行推广后其实大家面临的纵向分辨率被压榨的问题，所以简介的界面才会大受欢迎。但是我相信ff4.0会有很大的进步，我们在期待。js的处理效率问题是ff的老问题，改进引擎期望早点上线