如果相同功能的两段代码在不同浏览器上性能相反，有必要分浏览器优化吗？

[snw]

只是好奇问问，毕竟不是写 js 吃饭的。
比如只需要兼容少数主流浏览器，有同样功能的 function a()和试图优化后的 function b()。在 Firefox 上执行 a()要 2000ms，执行 b()只要 200ms ；在 Chrome 上执行 a()只需要 150ms，执行 b()需要 800ms。对用户体验可能有一点点影响但不大。
有必要根据浏览器分别用不同的 function 吗？还是直接选 b()就行？

V8 触发优化似乎有些难琢磨，又不想去搞 CrankShaftScript ……
示例： http://jsben.ch/GfA17

[dremy]

主要还是看需求，面向的用户，以及是否有足够的精力（时间），推荐优先保证 chrome。至于其它浏览器，毕竟这已经是优化层面了，完全可以后期迭代实现

[geelaw]

超过 50ms 是很容易让用户感受到的，2000ms、800ms 太吓人了。如果用户对 responsiveness 要求高的话需要处理。

我之前有一段必须跑很长时间的代码是通过异步的方式跑一会儿歇一会儿的方式跑完的。

[jadeity]

会有这么大的性能差异吗？

[hellowes]

不得不说 Chrome 执行效率秒杀同行。
同样的 echarts 页面，chrome 顺畅无比，firefox 总有一些卡顿的现象。
我猜和 chrome 高 CPU 高内存也有关，相比 chrome，firefox 就省电的多

[lrz0lrz]

@hellowes 难道不是 echarts 主要针对 chrome 做优化吗？

[lrz0lrz]

楼主的问题已经有答案了：
只需要优化 chrome，用户会认为是火狐的问题。

[hellowes]

@lrz0lrz 你这个专门优化的结论怎么得来的？求指教，哪一处算法代码的不同？还有只有 chrome 有 canvas，其他浏览器用的都是 svg ？
都是跑 JavaScript 的代码，firefox 卡顿就是卡顿，别找借口了

[hellowes]

@lrz0lrz 现在主流浏览器的代码都是遵循 ESMASCRIPT 标准的，只是内核执行速度问题而已，承认 v8 速度很困难吗

[VDimos]

有专门的介绍 v8 触发优化的方法的文章和论文，可以参考去看看

[autoxbc]

@hellowes 你读一下楼主的测试代码就懂了

理论上等价的代码，实际在不同内核触发 jit 上有区别，性能会差几倍，也就是所谓的 CrankShaftScript

[libook]

商业活动的话看 ROI。做优化方案以及代码的长期维护需要花费多大成本，目标用户中使用 Firefox 的用户有多大比重，能转化多少收益。
如果此时收益很小，那就不用做优化了，除非你们产品已经成熟到没有其他功能要做了，闲得蛋疼可以优化优化多浏览器兼容，以及 Accessible(无障碍)。