V8 性能优化杀手V8 性能优化杀手

<b>本文讲的是V8 性能优化杀手，</b>

<b></b>

这篇文章将会给你一些建议，让你避免写出性能远低于期望值的代码。在此特别指出有一些代码会导致 V8 引擎（涉及到 Node.JS、Opera、Chromium 等）无法对相关函数进行优化。

V8 引擎中没有解释器，但有 2 种不同的编译器：普通编译器与优化编译器。编译器会将你的 JavaScript 代码编译成汇编语言后直接运行。但这并不意味着运行速度会很快。被编译成汇编语言后的代码并不能显著地提高其性能，它只能省去解释器的性能开销，如果你的代码没有被优化的话速度依然会很慢。

例如，在普通编译器中 <code>a + b</code> 将会被编译成下面这样：

换句话说，其实它仅仅调用了 runtime 函数。但如果 <code>a</code> 和 <code>b</code> 能确定都是整型变量，那么编译结果会是下面这样：

它的执行速度会比前面那种去在 runtime 中调用复杂的 JavaScript 加法算法快得多。

通常来说，使用普通编译器将会得到前面那种代码，使用优化编译器将会得到后面那种代码。走优化编译器的代码可以说比走普通编译器的代码性能好上 100 倍。但是请注意，并不是任何类型的 JavaScript 代码都能被优化。在 JS 中，有很多种情况（甚至包括一些我们常用的语法）是不能被优化编译器优化的（这种情况被称为“bailout”，从优化编译器降级到普通编译器）。

记住一些会导致整个函数无法被优化的情况是很重要的。JS 代码被优化时，将会逐个优化函数，在优化各个函数的时候不会关心其它的代码做了什么（除非那些代码被内联在即将优化的函数中。）。

这篇文章涵盖了大多数会导致函数坠入“无法被优化的深渊”的情况。不过在未来，优化编译器进行更新后能够识别越来越多的情况时，下面给出的建议与各种变通方法可能也会变的不再必要或者需要修改。

<a href="https://juejin.im/post/5959edfc5188250d83241399#1-%E5%B7%A5%E5%85%B7" target="_blank">工具</a>

<a href="https://juejin.im/post/5959edfc5188250d83241399#2-%E4%B8%8D%E6%94%AF%E6%8C%81%E7%9A%84%E8%AF%AD%E6%B3%95" target="_blank">不支持的语法</a>

<a href="https://juejin.im/post/5959edfc5188250d83241399#3-%E4%BD%BF%E7%94%A8-arguments" target="_blank">使用 <code>arguments</code></a>

<a href="https://juejin.im/post/5959edfc5188250d83241399#4-switch-case" target="_blank">Switch-case</a>

<a href="https://juejin.im/post/5959edfc5188250d83241399#5-for-in" target="_blank">For-in</a>

<a href="https://juejin.im/post/5959edfc5188250d83241399#6-%E9%80%80%E5%87%BA%E6%9D%A1%E4%BB%B6%E8%97%8F%E7%9A%84%E5%BE%88%E6%B7%B1-%E6%88%96%E8%80%85%E6%B2%A1%E6%9C%89%E5%AE%9A%E4%B9%89%E6%98%8E%E7%A1%AE%E5%87%BA%E5%8F%A3%E7%9A%84%E6%97%A0%E9%99%90%E5%BE%AA%E7%8E%AF" target="_blank">退出条件藏的很深，或者没有定义明确出口的无限循环</a>

你可以在 node.js 中使用一些 V8 自带的标记来验证不同的代码用法对优化的影响。通常来说你可以创建一个包括特定模式的函数，然后使用所有允许的参数类型去调用它，再使用 V8 的内部去优化与检查它：

test.js:

运行它：

<a href="https://link.juejin.im/?target=https%3A%2F%2Fcodereview.chromium.org%2F1962103003" target="_blank">codereview.chromium.org/1962103003</a>

为了检验我们做的这个工具是否真的有用，注释掉 <code>eval</code> 语句然后再运行一次：

事实证明，使用这个工具来验证处理方法是可行且必要的。

有一些语法结构是不支持被编译器优化的，用这类语法将会导致包含在其中的函数不能被优化。

请注意，即使这些语句不会被访问到或者不会被执行，它仍然会导致整个函数不能被优化。

例如下面这样做是没用的：

即使 debugger 语句根本不会被执行到，上面的代码将会导致包含它的整个函数都不能被优化。

目前不可被优化的语法有：

包含 <code>const</code> 复合赋值的函数 （Chrome 56 / V8 5.6! 对其做了优化）

包含 <code>__proto__</code> 对象字面量、<code>get</code> 声明、<code>set</code> 声明的函数

看起来永远不会被优化的语法有：

包含 <code>debugger</code> 语句的函数

包含字面调用 <code>eval()</code> 的函数

包含 <code>with</code> 语句的函数

最后明确一下：如果你用了下面任何一种情况，整个函数将不能被优化：

另外在此要特别提一下 <code>eval</code> 和 <code>with</code>，它们会导致它们的调用栈链变成动态作用域，可能会导致其它的函数也受到影响，因为这种情况无法从字面上判断各个变量的有效范围。

变通办法

前面提到的不能被优化的语句用在生产环境代码中是无法避免的，例如 <code>try-finally</code> 和 <code>try-catch</code>。为了让使用这些语句的影响尽量减小，它们需要被隔离在一个最小化的函数中，这样主要的函数就不会被影响：

有许多种使用 <code>arguments</code> 的方式会导致函数不能被优化。因此当使用 <code>arguments</code> 的时候需要格外小心。

变通方法 是将参数值保存在一个新的变量中：

如果仅仅是像上面这样用 <code>arguments</code>（上面代码作用为检测第二个参数是否存在，如果不存在则赋值为 5），也可以用 <code>undefined</code> 检测来代替这段代码：

但是之后如果需要用到 <code>arguments</code>，很容易忘记需要在这儿加上重新赋值的语句。

变通方法 2：为整个文件或者整个函数开启严格模式 （<code>'use strict'</code>）。

<code>arguments</code> 对象在任何地方都不允许被传递或者被泄露。

变通方法 可以通过创建一个数组来代理 <code>arguments</code> 对象：

但是这样要写很多让人烦的代码，因此得判断是否真的值得这么做。后面一次又一次的优化会代理更多的代码，越来越多的代码意味着代码本身的意义会被逐渐淹没。

不过，如果你有 build 这个过程，可以将上面这一系列过程由一个不需要 source map 的宏来实现，保证代码为合法的 JavaScript：

Bluebird 就使用了这个技术，上面的代码经过 build 之后会被拓展成下面这样：

在非严格模式下可以这么做：

变通方法：犯不着写这么蠢的代码。另外，在严格模式下它会报错。

只使用：

<code>arguments.length</code>

<code>arguments[i]</code> <code>i</code> 需要始终为 arguments 的合法整型索引，且不允许越界

除了 <code>.length</code> 和 <code>[i]</code>，不要直接使用 <code>arguments</code>

严格来说用 <code>fn.apply(y, arguments)</code> 是没问题的，但除此之外都不行（例如 <code>.slice</code>）。<code>Function#apply</code> 是特别的存在。

请注意，给函数添加属性值（例如 <code>fn.$inject = ...</code>）和绑定函数（即 <code>Function#bind</code>的结果）会生成隐藏类，因此此时使用 <code>#apply</code> 不安全。

如果你按照上面的安全方式做，毋需担心使用 <code>arguments</code> 导致不确定 arguments 对象的分配。

在以前，一个 switch-case 语句最多只能包含 128 个 case 代码块，超过这个限制的 switch-case 语句以及包含这种语句的函数将不能被优化。

你需要让 case 代码块的数量保持在 128 个之内，否则应使用函数数组或者 if-else。

For-in 语句在某些情况下会导致整个函数无法被优化。

这也解释了”For-in 速度不快“之类的说法。

这两种用法db都将会导致函数不能被优化的问题。因此键不能在上级作用域定义，也不能在下级作用域被引用。它必须是一个局部变量。

如果你给一个对象动态增加了很多的属性（在构造函数外）、<code>delete</code> 属性或者使用不合法的标识符作为属性，这个对象将会变成哈希表模式。换句话说，当你把一个对象当做哈希表来用，它就真的会变成哈希表。请不要对这种对象使用 <code>for-in</code>。你可以用过开启 Node.JS 的<code>--allow-natives-syntax</code>，调用 <code>console.log(%HasFastProperties(obj))</code> 来判断一个对象是否为哈希表模式。

上面这么做会给所有对象（除了用 <code>Object.create(null)</code> 创建的对象）的原型链中添加一个可枚举属性。此时任何包含了 <code>for-in</code> 语法的函数都不会被优化（除非仅遍历<code>Object.create(null)</code> 创建的对象）。

你可以使用 <code>Object.defineProperty</code> 创建不可枚举属性（不推荐在 runtime 中调用，但是在定义一些例如原型属性之类的静态数据的时候它很高效）。

数组对象会给予一些种类的属性名特殊待遇。对一个属性名 P（字符串形式），当且仅当 ToString(ToUint32(P)) 等于 P 并且 ToUint32(P) 不等于 232−1 时，它是个 数组索引 。一个属性名是数组索引的属性也叫做元素 。

一般只有数组有数组索引，但是有时候一般的对象也可能拥有数组索引： <code>normalObj[0] = value;</code>

因此使用 <code>for-in</code> 进行数组遍历不仅会比 for 循环要慢，还会导致整个包含 <code>for-in</code> 语句的函数不能被优化。

如果你试图使用 <code>for-in</code> 遍历一个非简单可枚举对象，它会导致包含它的整个函数不能被优化。

变通方法：只对 <code>Object.keys</code> 使用 <code>for-in</code>，如果要遍历数组需使用 for 循环。如果非要遍历整个原型链上的属性，需要将 <code>for-in</code> 隔离在一个辅助函数中以降低影响：

有时候在你写代码的时候，你需要用到循环，但是不确定循环体内的代码之后会是什么样子。所以这时候你用了一个 <code>while (true) {</code> 或者 <code>for (;;) {</code>，在之后将终止条件放在循环体中，打断循环进行后面的代码。然而你写完这些之后就忘了这回事。在重构时，你发现这个函数很慢，出现了反优化情况 - 上面的循环很可能就是罪魁祸首。

重构时将循环内的退出条件放到循环的条件部分并不是那么简单。

如果代码中的退出条件是循环最后的 if 语句的一部分，且代码至少要运行一轮，那么你可以将这个循环重构为 <code>do{} while ();</code>。

如果退出条件在循环的开头，请将它放在循环的条件部分中去。

如果退出条件在循环体中部，你可以尝试”滚动“代码：试着依次将一部分退出条件前的代码移到后面去，然后在之前的位置留下它的引用。当退出条件可以放在循环条件部分，或者至少变成一个浅显的逻辑判断时，这个循环就不再会出现反优化的情况了。

<b>原文发布时间为：2017年7月3日</b>

<b>本文来自云栖社区合作伙伴掘金，了解相关信息可以关注掘金网站。</b>