【问题标题】:What are the best practices for optimising JavaScript for (potential) future browser assembly-language optimisations?为(潜在的)未来浏览器汇编语言优化优化 JavaScript 的最佳实践是什么?
【发布时间】:2013-05-20 14:14:37
【问题描述】:

据我了解,Chrome 中的 V8 引擎一直在使用汇编级优化,现在(在撰写本文时)即将在 Firefox 上发布的 OdinMonkey 表明大量的低级优化正在写入JavaScript 浏览器。

我希望这是在 SO 的礼仪之内,但我的问题是三个方面...

  1. (我想可能会删除一个特定的问题)——关于 Firefox 的 OdinMonkey/asm.js 优化——这是“我们”必须专门编写的代码吗?还是它类似于 V8 引擎,因为这一切都发生在“幕后”?我看到的关于这个特定主题的资料似乎相互矛盾。

  2. 更一般地说(也许是一个更相关的问题)是否有关于编写 JavaScript 以更好地“提前”/组装/等的最佳实践。优化?例如,我读到使用按位移位来舍入数字可能会改善优化,但是,根据浏览器的不同,它可能几乎没有收益。

  3. 将其纳入第三个问题以防止混淆 — 最后,客户端装配级优化是否毫无结果? “我们”作为编码人员是否应该尽我们所能来生成高效的 JavaScript 代码,并让优化程序尽其所能?

【问题讨论】:

  • asm.js 必须专门编码;它是 JavaScript 的一个(非常)限制性子集。除此之外……相当主观的领域:)
  • 不要为它编码。是的,我说过。相反,特定浏览器/环境中的特定代码段运行性能配置文件,并努力优化该iff 它恰好“太慢”。也就是说,我相信它会更有成果为效果编码而不是实现..
  • 感谢 rynah 和用户.... 我认为那里的“iff”非常重要。也许我太挑剔了\只关注代码的一个小方面,而不是更大的图景!谢谢

标签: javascript assembly browser v8


【解决方案1】:

您必须通过 using only low-level constructs and strict typing 专门针对 asm.js。一次违反众多 asm.js 限制将中止整个编译并回退到常规 JS VM。

您不能仅通过调整现有的 JS 代码来利用 asm.js。不能保证 asm.js 风格的 JS 在常规 JS VM 中会更快。它可能更适合优化,但 OTOH asm.js 需要大量转换,其他 VM 可能也无法优化。

对于 V8 和 Firefox 的其他 VM Zoo 规则是相同的——不要混合类型,不要在任何地方使用 evalwith,等等。

【讨论】: