V8 最佳实践：从 JavaScript 变量使用姿式提及

| 导语 在弱类型语言 JavaScript 中，变量上能有多少优化窍门？本文从最基础的变量类型提及，带你深刻 V8 底层类型变换与优化机制。真正的老司机，一行代码可见一斑。之后你能够说，我写的代码，连变量声明都比你快…

本文参考 V8 开发者博客中关于 React 性能断崖的一篇分析，细节不少，整理一下与你们分享。

JavaScript 做为弱类型语言，咱们能够对一个变量赋予任意类型值，但即便如此，对于各种 JavaScript 值，V8 仍须要对不一样类型值应用特定的内存表示方式。充分了解底层原理后，咱们甚至能够从变量使用方式上入手，写出更加优雅、符合引擎行为的代码。

先从为人熟知的 JavaScript 8大变量类型讲起。

JavaScript 变量类型

八大变量类型

按照当前 ECMAScript 规范，JavaScript 中值的类型共有如下八种：Number,String,Symbol,BigInt,Boolean,Undefined,Null,Object。

这些类型值均可以经过typeof操做符监测到，除了一个例外：

typeof 42;
// → 'number'
typeof 'foo';
// → 'string'
typeof Symbol('bar');
// → 'symbol'
typeof 42n;
// → 'bigint'
typeof true;
// → 'boolean'
typeof undefined;
// → 'undefined'
typeof null;
// → 'object' 注意这里
typeof { x: 42 };
// → 'object'
复制代码

为何 typeof null === 'object'

在规范中，Null虽然做为null自己的类型，但typeof null却返回object。想知道背后的设计原理，首先要了解 JavaScript 中的一个定义，在 JavaScript 中全部类型集合都被分为两个组：

• objects（引用类型，好比Object的类型）
• primitives（原始类型，全部非引用类型的值）

在定义中，null意为no object value，而undefined意为no value。

按照上图构想，JavaScript 的创始人 Brendan Eich 在设计之初就将属于objects和null类型集合下的全部类型值统一返回了'object'类型。

事实上，这是当时受到了 Java 的影响。在 Java 中，null历来就不是一个单独的类型，它表明的是全部引用类型的默认值。这就是为何尽管规范中规定了null有本身单独的Null类型，而typeof null仍旧返回'object'的缘由。

值的内存表示方式

JavaScript 引擎必须可以在内存中表示任意值，而须要注意的是，同一类型值其实也会存在不一样的内存表示方式。

好比值42在 JavaScript 中的类型是number：

typeof 42;
// → 'number'
复制代码

而在内存上有许多种方式能够用来表示42：

representation	bits
8位二进制补码	0010 1001
32位二进制补码	0000 0000 0000 0000 0000 0000 0010 1010
二进制编码的十进数码	0100 0010
32位 IEEE-754 单精度浮点	0100 0010 0010 1000 0000 0000 0000 0000
64位 IEEE-754 双精度浮点	0100 0000 0100 0101 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

ECMAScript 标准约定number数字须要被当成 64 位双精度浮点数处理，但事实上，一直使用 64 位去存储任何数字实际是很是低效的，因此 JavaScript 引擎并不总会使用 64 位去存储数字，引擎在内部能够采用其余内存表示方式（如 32 位），只要保证数字外部全部能被监测到的特性对齐 64 位的表现就行。

例如咱们知道，ECMAScript 中的数组合法索引范围在[0, 2³²−2]：

array[0]; // Smallest possible array index.
array[42];
array[2**32-2]; // Greatest possible array index.
复制代码

经过下标索引访问数组元素时，V8 会使用 32 位的方式去存储这些合法范围的下标数字，这是最佳的内存表示方式。用 64 位去存储数组下标会致使极大浪费，每次访问数组元素时引擎都须要不断将 Float64 转换为二进制补码，此时若使用 32 位去存储下标则能省下一半的转换时间。

32 位二进制补码表示法不只仅应用在数组读写操做中，全部[0, 2³²−2]内的数字都会优先使用 32 位的方式去存储，而通常来讲，处理器处理整型运算会比处理浮点型运算快得多，这就是为何在下面例子里，第一个循环的执行效率比第二个循环的执行效率快上将近两倍：

for (let i = 0; i < 100000000; ++i) {
  // fast → 77ms
}

for (let i = 0.1; i < 100000000.1; ++i) {
  // slow → 122ms
}
复制代码

对运算符也是同样，下面例子中 mol 操做符的执行性能取决于两个操做数是否为整型：

const remainder = value % divisor;
// Fast: 若是`value`和`divisor`都是被当成整型存储
// slow: 其余状况
复制代码

值得一提的是，针对 mol 运算，当divisor的值是 2 的幂时，V8 为这种状况添加了额外的快捷处理路径。

另外，整型值虽然能用32位去存储，可是整型值之间的运算结果仍有可能产生浮点型值，而且 ECMAScript 标准自己是创建在 64 位的基础上的，所以规定了运算结果也必须符合 64 位浮点的表现。这个状况下，JS 引擎须要特别确保如下例子结果的正确性：

// Float64 的整数安全范围是 53 位，超过这个范围数值会失去精度
2**53 === 2**53+1;
// → true

// Float64 支持负零，因此 -1 * 0 必须等于 -0，可是在 32 位二进制补码中没法表示出 -0
-1*0 === -0;
// → true

// Float64 有无穷值，能够经过和 0 相除得出
1/0 === Infinity;
// → true
-1/0 === -Infinity;
// → true

// Float64 有 NaN
0/0 === NaN;
复制代码

Smi、HeapNumber

针对 31 位有符号位范围内的整型数字，V8 为其定义了一种特殊的表示法Smi，其余任何不属于Smi的数据都被定义为HeapObject，HeapObject表明着内存的实体地址。

对于数字而言，非Smi范围内的数字被定义为HeapNumber，HeapNumber是一种特殊的HeadObject。

-Infinity // HeapNumber
-(2**30)-1 // HeapNumber
  -(2**30) // Smi
       -42 // Smi
        -0 // HeapNumber
         0 // Smi
       4.2 // HeapNumber
        42 // Smi
   2**30-1 // Smi
     2**30 // HeapNumber
  Infinity // HeapNumber
       NaN // HeapNumber
复制代码

Smi范围的整型数在 JavaScript 程序中很是经常使用，所以 V8 针对Smi启用了一个特殊优化：当使用Smi内的数字时，引擎不须要为其分配专门的内存实体，并会启用快速整型操做。

经过以上讨论咱们能够知道，即便值拥有相同的 JavaScript 类型，引擎内部依然可使用不一样的内存表示方式去达到优化的手段。

Smi vs HeapNumber vs MutableHeapNumber

Smi与HeapNumber是如何运做的呢？假设咱们有一个对象：

const o = {
  x: 42,  // Smi
  y: 4.2, // HeapNumber
};
复制代码

o.x中的42会被当成Smi直接存储在对象自己，而o.y中的4.2须要额外开辟一个内存实体存放，并将o.y的对象指针指向该内存实体。

此时，当咱们运行如下代码片断：

o.x += 10;
// → o.x is now 52
o.y += 1;
// → o.y is now 5.2
复制代码

在这个状况下，o.x的值会被原地更新，由于新的值52仍在Smi范围中。而HeapNumber是不可变的，当咱们改变o.y的值为5.2时，V8 须要再开辟一个新的内存实体给到o.y引用。

借助HeapNumber不可变的特性，V8 能够启用一些手段，如如下代码，咱们将o.y的值引用赋予o.x：

o.x = o.y;
// → o.x is now 5.2
复制代码

在这样的状况下，V8 不须要再为o.x新的值5.2去开辟一块内存实体，而是直接使用同一内存引用。

在具备以上优势的同时，HeapNumber不可变的特性也有一个缺陷，若是咱们须要频繁更新HeapNumber的值，执行效率会比Smi慢得多：

// 建立一个`HeapNumber`对象
const o = { x: 0.1 };

for (let i = 0; i < 5; ++i) {
  // 建立一个额外的HeapNumber对象
  o.x += 1;
}
复制代码

在这个短暂的循环中，引擎不得不建立 6 个HeapNumber实例，0.1、1.1、2.1、3.1、4.1、5.1，而等到循环结束，其中 5 个实例都会成为垃圾。

为了防止这个问题，V8 提供了一种优化方式去原地更新非Smi的值：当一个数字内存区域拥有一个非Smi范围内的数值时，V8 会将这块区域标志为Double区域，并会为其分配一个用 64 位浮点表示的MutableHeapNumber实例。

此后当你再次更新这块区域，V8 就再也不须要建立一个新的HeapNumber实例，而能够直接在MutableNumber实例中进行更新了。

前面说到，HeapNumber和MutableNumber都是使用指针引用的方式指向内存实体，而MutableNumber是可变的，若是此时你将属于MutableNumber的值o.x赋值给其余变量y，你必定不但愿你下次改变o.x时，y也跟着改变。 为了防止这种状况，当o.x被共享时，o.x内的MutableHeapNumber须要被从新封装成HeapNumber传递给y：

Shape 的初始化、弃用与迁移

不一样的内存表示方式对应不一样的Shape，Shape 能够理解为数据结构类同样的存在。

问题来了，若是咱们一开始给一个变量赋值Smi范围的数字，紧接着再赋值HeapNumber范围的数字，引擎会怎样处理呢？

下面例子，咱们用相同的数据结构建立两个对象，并将对象中的x值初始化为Smi：

const a = { x: 1 };
const b = { x: 2 };
// → objects have `x` as `Smi` field now

b.x = 0.2;
// → <span class="javascript">b.x</span> is now represented as a <span class="javascript">Double</span>
y = a.x;
复制代码

这两个对象指向相同的数据结构，其中x都为Smi。

紧接着当咱们修改b.x数值为0.2时，V8 须要分配一个新的被标志为Double的 Shape 给到b，并将新的 Shape 指针从新指向回空 Shape，除此以外，V8 还须要分配一个MutableHeapNumber实例去存储这个0.2。然后 V8 但愿尽量复用 Shape，紧接着会将旧的 Shape 标志为deprecated。

能够注意到此时a.x其实仍指向着旧 Shape，V8 将旧 Shape 标志为deprecaed的目的显然是要想移除它，但对于引擎来讲，直接遍历内存去找到全部指向旧 Shape 的对象并提早更新引用，实际上是很是昂贵的操做。V8 采用了懒处理方案：当下一次a发生任何属性访问和赋值时再将a的 Shape 迁移到新的 Shape 上。这个方案最终可使得旧 Shape 失去全部引用计数，而只需等待垃圾回收器释放它。

小结

咱们深刻讨论了如下知识点：

• JavaScript 底层对primitives和objects的区分，以及typeof的不许确缘由。
• 即便变量的值拥有相同的类型，引擎底层也可使用不一样的内存表示方式去存储。
• V8 会尝试找一个最优的内存表示方式去存储你 JavaScript 程序中的每个属性。
• 咱们讨论了 V8 针对 Shape 初始化、弃用与迁移的处理方案。

基于这些知识，咱们能够得出一些能帮助提升性能的 JavaScript 编码最佳实践：

• 尽可能用相同的数据结构去初始化你的对象，这样对 Shape 的利用是最高效的。
• 为你的变量选择合理的初始值，让 JavaScript 引擎能够直接使用对应的内存表示方式。
• write readable code, and performance will follow

咱们经过了解复杂的底层知识，得到了很简单的编码最佳实践，或许这些点能带来的性能提高很小。但所谓厚积薄发，偏偏是清楚这些有底层理论支撑着的优化点，咱们写代码时才能作到心中有数。

另外我很喜欢这类以小见大的技术点，之后当别人问你为何要这样声明变量时，你每每就能开始表演……

参考文章： The story of a V8 performance cliff in React

原文连接：yangzicong.com/article/14