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