[譯]V8引擎中的排序

V8引擎中的排序

本文於 2018年9月28日，在V8開發者博客中發佈

翻譯僅作學習交流，轉載請註明出處，商業用途請自行聯繫原文版權全部者

做者：Simon Zünd (@nimODota)

譯者：Smith

Array.prototype.sort 是V8引擎中最後一批採用JavaScript自託管實現的內置函數之一。在移植它的過程當中，咱們進行了不一樣算法和實施策略的實驗，最終在V8引擎的7.0（Chrome 70）中發佈了排序穩定的版本。

背景

在JavaScript中排序並不簡單。這篇博客介紹了排序算法和JavaScript語言特性結合中的一些問題，並記錄了咱們將V8轉移到穩定算法並使性能更具可預測性的過程。

當比較不一樣的排序算法時，咱們將它們的最差性能和平均性能，看做是對內存訪問或比較次數的漸近增加（即「大O」符號）的約束。請注意，在動態語言（如JavaScript）中，比較操做一般比內存訪問更昂貴。這是由於在排序時比較兩個值一般涉及對用戶代碼的調用。

譯註：客戶代碼理解爲排序中引擎外的代碼，好比咱們再用Array.prototype.sort通常會傳入回調函數 [...].sort((a, b)=> a-b); 沒有回調的狀況也會有值處理，好比[1,'2']，在比較數字和字符串前，Javascript會作類型轉換。

讓咱們看一個簡單的示例：基於用戶提供的比較函數將一些數字按升序排序的。當a比b更小、相等、更大時，比較函數分別返回-1（或任何其餘負值）、0、1（或任何其餘正值）。不遵循此模式的比較函數則不兼容，而且可能具備任意反作用，例如修改要排序的數組。

const array = [4, 2, 5, 3, 1];

function compare(a, b) {
  // 任意代碼, 例如 `array.push(1);`
  return a - b;
}

// 一個「典型的」sort調用
array.sort(compare);
複製代碼

即便在下面這個不傳入回調函數的示例中，也可能會發生對用戶代碼的調用。比較函數，「默認」地，會在兩個要比較的值上調用toString，並對返回的兩個字符串進行字典比較。

const array = [4, 2, 5, 3, 1];

array.push({
  toString() {
    // 任意代碼, 例如 `array.push(1);`
    return '42';
  }
});

// 沒有比較函數的sort
array.sort();
複製代碼

更有趣的是，屬性訪問器和原型鏈的相互影響

在本節內容中，咱們拋開規範，開始嘗試「定義具體實現」的旅程。規範有一個完整的條件列表，當知足時，容許引擎用它認爲合適的方式，對對象/數組進行排序 - 或者根本不對它進行排序。雖然排序的使用者必須遵循一些基本規則，但其餘的一切幾乎都在空氣中（拋諸腦後，無論不顧的意思）。一方面，這使得引擎開發人員能夠自由地嘗試不一樣的實現。另外一方面，用戶期獲得一些合理的表現，即便規範中並無要求。因爲「合理的表現」並不老是直接明肯定義的，致使事情變得更加複雜。

本節說明，在不一樣的引擎中，Array#sort在一些方面仍然表現出很大的差異。這些大可能是一些邊緣的場景，如上所述，在這些場景中，並不老是明確「合理的表現」應該是什麼。咱們強烈建議不要編寫這樣的代碼，引擎不會優化它。

第一個示例顯示了，在不一樣JavaScript引擎中一個數組的排序過程，其中包含一些內存訪問（即getter和setter）以及「日誌打印」。訪問器是第一個例子，展現「定義具體實現」對排序結果的影響：

const array = [0, 1, 2];

Object.defineProperty(array, '0', {
  get() { console.log('get 0'); return 0; },
  set(v) { console.log('set 0'); }
});

Object.defineProperty(array, '1', {
  get() { console.log('get 1'); return 1; },
  set(v) { console.log('set 1'); }
});

array.sort();
複製代碼

下面是不一樣Javascript引擎中這段代碼的輸出。請注意，這裏沒有「正確」或「錯誤」的答案 -- 由於規範中並無明確，而是將其留給不一樣引擎的實現！

get 0
get 1
set 0
set 1

// JavaScriptCore
get 0
get 1
get 0
get 0
get 1
get 1
set 0
set 1

// V8
get 0
get 0
get 1
get 1
get 1
get 0

#### SpiderMonkey
get 0
get 1
set 0
set 1
複製代碼

下一個示例展現了原型鏈對排序結果的影響。爲簡潔起見，咱們不進行日誌打印。

const object = {
 1: 'd1',
 2: 'c1',
 3: 'b1',
 4: undefined,
 __proto__: {
   length: 10000,
   1: 'e2',
   10: 'a2',
   100: 'b2',
   1000: 'c2',
   2000: undefined,
   8000: 'd2',
   12000: 'XX',
   __proto__: {
     0: 'e3',
     1: 'd3',
     2: 'c3',
     3: 'b3',
     4: 'f3',
     5: 'a3',
     6: undefined,
   },
 },
};
Array.prototype.sort.call(object);
複製代碼

下面是這個 對象 執行排序後的結果。一樣，這裏沒有所謂的正確答案。此示例僅展現了索引屬性與原型鏈之間的交互有多奇怪：

譯註：相似僞數組

// Chakra
['a2', 'a3', 'b1', 'b2', 'c1', 'c2', 'd1', 'd2', 'e3', undefined, undefined, undefined]

// JavaScriptCore
['a2', 'a2', 'a3', 'b1', 'b2', 'b2', 'c1', 'c2', 'd1', 'd2', 'e3', undefined]

// V8
['a2', 'a3', 'b1', 'b2', 'c1', 'c2', 'd1', 'd2', 'e3', undefined, undefined, undefined]

// SpiderMonkey
['a2', 'a3', 'b1', 'b2', 'c1', 'c2', 'd1', 'd2', 'e3', undefined, undefined, undefined]
複製代碼

V8在實際排序以前作了什麼

V8在實際排序以前有兩個預處理步驟。

首先，若是要排序的對象在原型鏈上有孔和元素，會將它們從原型鏈複製到對象自己。這樣在後續全部步驟中，咱們都不須要再關注原型鏈。目前，V8只會對非標準的JSArrays進行這樣的處理，而其它引擎對於標準的JSArrays也會進行這樣的複製處理。

第二個預處理步驟是去孔（hole）。V8引擎會將排序範圍中的全部元素都移動到對象的開頭。以後移動 undefined。這在某種程度上實際上是規範所要求的，由於規範要求引擎始終將undefined排序到最後。這樣nbbbb，undefined永遠都不會做爲的參數去調用用戶提供的比較函數。在第二個預處理步驟以後，排序算法只須要考慮 非undefined的，這能夠減小實際排序的元素的數量。

歷史

Array.prototype.sort 和 TypedArray.prototype.sort 都基於同一種用JavaScript編寫的Quicksort實現。排序算法自己很是簡單：基礎是一個Quicksort（快速排序），對於較短的數組（長度<10）則降級爲插入排序（Insertion Sort）。

當Quicksort在分治的處理中遞歸出長度小於10的子數組時，也使用插入排序處理。由於插入排序對於較短的數組更高效。這是由於Quicksort在分區後，須要遞歸調用兩次。每一個這樣的遞歸調用都有建立（和丟棄）棧幀的開銷。

因此選擇合適的軸元素（pivot）對Quicksort的性能有着很大的影響。V8採用了兩條策略：

• 找到數組中的第一個，最後一個和「第三個」元素，而後選擇這三個元素的中間值做爲pivot。對於較短數組，「第三個」的的元素就是中間 元素。
• 對於較長的數組，就從中抽出一個小數組進行排序，並將排序後中位數做爲上述計算中的「第三個」元素。

Quicksort的優勢之一是：它是就地排序，不須要太多的內存開銷。只有在處理大型數組時，須要爲選擇的樣本數組分配內存，以及log（n）棧空間。它的缺點是：它不是穩定的排序算法，而且在最壞狀況下，時間複雜度會降級到O（n^2）。

介紹 V8 Torque

若是您是V8開發者博客的愛好者，可能據說過 CodeStubAssembler，或簡稱 CSA。CSA是V8的一個組件，它容許咱們直接用C ++編寫低級別的TurboFan IR（TurboFan 中間層，見譯註），後來用TurboFan的後端（編譯器後端）將其合理結構的機器碼。

譯註：見CSA的連接，比較早了。TurboFan IR是V8本身搞的，相比於傳統的基於圖的中間層，特別作了些優化，想具體瞭解的話搜搜大牛的文章吧

CSA被大量應用於爲JavaScript內置函數編寫所謂的「快速路徑」。內置的「快速路徑」版本一般檢查某些特別的條件是否成立（例如原型鏈上沒有元素，沒有訪問器等），而後使用更快，更特殊優化的操做來實現內置函數的功能。這可使函數執行時間比通用版本快一個數量級。

CSA的缺點是它確實能夠被認爲是彙編語言。流程控制使用明確的 label 和 goto進行建模，這使得在CSA中實現複雜算法時，代碼會難以閱讀且容易出錯。

而後是V8 Torque。Torque是一種領域專用語言，具備相似TypeScript的語法，目前使用CSA做爲其惟一的編譯目標。Torque容許開發者使用與CSA幾乎相同層次的流程控制操做，同時提供更高級別的構造，例如while和for循環。此外，它是強類型的，而且未來還會包含相似自動越界這樣的安全檢查，爲V8引擎的工程師提供更強大的保障。

用V8 Torque重寫的第一個重要的內置函數是 TypedArray＃sort 和 Dataview。這二者的重寫都有另外的目的，即向Torque開發人員反饋所須要的語言功能，以及使用哪些模式會能夠更高效地編寫內置函數。在撰寫本文時，多個JSArray的內置函數和對應的自託管的JavaScript後降級實現，已經遷移至Torque（例如，Array＃unshift），其他的則被徹底重寫（例如，Array＃splice和Array＃reverse）。

將 Array # sort 遷移到 Torque

最初的Array＃sort Torque版本或多或少能夠說就是JavaScript實現的直接搬運。惟一的區別是，對較長的數組不進行小數組採樣，而是隨機選擇數組中的某個元素做爲軸元素選擇中的「第三個」元素。

這種方式運行得至關不錯，但因爲它仍然使用Quicksort，所以 Array＃sort仍然是不穩定。請求穩定版本的Array＃sort 是V8的bug記錄器中最古老的工單之一。接下來嘗試用Timsort替代，在這個嘗試中咱們獲得了多種好處。首先，咱們喜歡它是一個穩定的算法，並提供一些很好的算法保證（見下一節）。其次，Torque仍然是一個正在開發中的項目，在Torque中用Timsort實現複雜的內置函數，例如「Array＃sort」，能夠給Torque語言的自己帶來不少可操做性的建議。

TimSort

最先由蒂姆·彼得斯（Tim Peters）於2002年開發的Timsort，能夠被認爲是自適應的穩定的歸併排序（Mergesort）的變種。其實現細節至關複雜，最好去參閱做者本人的說明或 維基百科，基礎概念應該很容易理解。雖然Mergesort使用遞歸的方式，但Timsort是以迭代進行。Timsort從左到右迭代一個數組，並尋找所謂的_runs_。一個run能夠認爲是已經排序的小數組，也包括以逆向排序的，由於這些數組能夠簡單地翻轉（reverse）就成爲一個run。在排序過程開始時，算法會根據輸入數組的長度，肯定一個run的最小長度。若是Timsort沒法在數組中找到知足這個最小長度的run，則使用插入排序（Insertion Sort）「人爲地生成」一個run。

找到的 runs在一個棧中追蹤，這個棧會記錄起始的索引位置和每一個run的長度。棧上的run會逐漸合併在一塊兒，直到只剩下一個排序好的run。在肯定合併哪些run時，Timsort會試圖保持兩方面的平衡。一方面，您但願儘早嘗試合併，由於這些run的數據極可能已經在緩存中，另外一方面，您但願儘量晚地合併，以利用數據中可能出現的某些特徵。爲了實現這個平衡，Timsort遵循保兩個原則。假設A，B和C是三個最頂級的runs：

• |C| > |B| + |A|
• |B| > |A|

譯註：這裏的大於指長度大於

在上圖的例子中，由於| A |> | B |，因此B被合併到了它先後兩個runs（A、C）中較小的一個。請注意，Timsort僅合併連續的run，這是維持算法穩定性所必需的，不然大小相等元素會在run中轉移。此外，第一個原則確保了run的長度，最慢也會以斐波那契（Fibonacci）數列增加，這樣當咱們知道數組的最大邊界時，runs棧大小的上下界也能夠肯定了。

如今能夠看出，對於已經排序好的數組，會以O（n）的時間內完成排序，由於這樣的數組將只產生單個run，不須要合併操做。最壞的狀況是O（n log n）。這樣的算法性能參數，以及Timsort天生的穩定性是咱們最終選擇Timsort而非Quicksort的幾個緣由。

在 Torque 中實現 Timsort

內置函數一般具備不一樣的代碼版本，在運行時（runtime）會根據各類變量選擇合適的代碼版本。而通用的版本則能夠處理任何類型的對象，不管它是一個JSProxy，有攔截器，仍是在查找/設置屬性時有原型鏈查詢。

在大多數狀況下，通用的路徑版本至關慢，由於它須要考慮全部的可能性。可是若是咱們事先知道要排序的對象是一個只包含Smis的簡單JSArray，全部這些昂貴的[[Get]]和[[Set]]操做均可以被簡單地替換爲FixedArray的Loads和Stores。主要的區別在於ElementsKind。

譯註：ElemenKind簡單來說，就是一個數組的元素類型，好比[1, 2]是ElementKind是Int，[1, 2.1]則是Double

如今問題變成了如何實現快速路徑。除了基於ElementsKind的不一樣更改訪問元素的方式以外，核心算法對全部場景保持相同。一種實現方案是：對每一個操做都分配合適的「訪問器（accessor）」。想象一下每一個「加載」/「存儲」（「load」/」store」）都有一個開關，咱們經過開關來選擇不一樣快速路徑的分支。

另外一個實現方案（這是最開始嘗試的方式）是爲對每一個快速路徑都複製整個內置函數並內聯合適的加載/存儲方法（load/store）。但這種方式對於Timsort來講是不可行的，由於它是一個很大的內置函數，複製每一個快速路徑總共須要106 KB的空間，這對於單個內置函數來講太過度了。

最終的方案略有不一樣。每一個快速路徑的每一個加載/存儲方法（load/store）都被放入其本身的「迷你內置函數」中。請參閱代碼示例，其中展現了針對「FixedDoubleArray」的「加載」（load）操做。

Load<FastDoubleElements>(
    context: Context, sortState: FixedArray, elements: HeapObject,
    index: Smi): Object {
  try {
    const elems: FixedDoubleArray = UnsafeCast<FixedDoubleArray>(elements);
    const value: float64 =
        LoadDoubleWithHoleCheck(elems, index) otherwise Bailout;
    return AllocateHeapNumberWithValue(value);
  }
  label Bailout {
    // 預處理步驟中，經過把全部元素移到數組最前的方式 已經移除了全部的孔
    // 這時若是找到了孔，說明 cmp 函數或 ToString 改變了數組
    return Failure(sortState);
  }
}
複製代碼

相比之下，最通用的「加載」操做（load）只是對GetProperty的調用。相比於上述版本生成了高效且快速的機器代碼來加載和轉換Number，GetProperty只是對另外一個內置函數的調用，這之中可能涉及對原型鏈的查找或訪問器函數的調用。

builtin Load<ElementsAccessor : type>(
    context: Context, sortState: FixedArray, elements: HeapObject,
    index: Smi): Object {
  return GetProperty(context, elements, index);
}
複製代碼

這樣一來，快速路徑就變成一組函數指針。這意味着咱們只須要核心算法的一個副本，同時預先設置全部相關函數的指針。雖然這大大減小了所需的代碼空間（低至20k），但卻以每一個訪問點的使用不一樣的間接分支作爲減小的代價。這種狀況在最近引入嵌入式內置函數的變動後加重了。

排序狀態

上圖顯示了「排序狀態」。它是一個FixedArray，展現了排序時涉及到的全部內容。每次調用Array＃sort時，都會分配這種排序狀態。期中04到07是上面討論的構成快速路徑的一組函數指針。

每次在用戶的JavaScript代碼返回（return）時都會調用內置函數「check」，以檢查咱們是否能夠繼續使用當前的快速路徑。它使用「initial receiver map」和「initial receiver length」來作檢查。若是用戶代碼修改了當前對象，咱們只需放棄排序運行，將全部指針重置爲最通用的版本並從新啓動排序的過程。08中的「救助狀態」做爲重置的信號。 「compare」能夠指向兩個不一樣的內置函數。一個調用用戶提供的比較函數，另外一個上面說的默認比較（對兩個參數執行toString，而後進行字典比較）。

其他字段（14：Fast path ID除外）都是Timsort所特有的。運行時的run棧（如上所述）初始化長度爲85，這足以對長度爲264的數組進行排序。而用於合併運行臨時數組的長度，會根據運行時的須要所增大，但毫不超過n / 2，其中n是輸入數組的長度。

性能妥協

將 Array # sort 的自託管JavaScript實現轉移到Torque須要進行一些性能權衡。因爲Array＃sort是用Torque編寫的，它如今是一段靜態編譯的代碼，這意味着咱們仍然能夠爲默認特定的 ElementsKind`s構建快速路徑，但它永遠不會比 TurboFan 高度優化的代碼更快，由於TurboFan能夠利用類型反饋進行優化。另外一方面，若是代碼沒有足夠熱以保證JIT編譯或者調用點是復態（megamorphic）的，咱們就會被卡在解釋器或慢速/通用的版本。自託管JavaScript實現版本中的解析，編譯和可能的優化過程當中所產生的開銷，在Torque實現版本中也都不須要了。

雖然Torque的實現方案沒法讓排序達到相同峯值性能，但它確實避免了性能斷崖。結果是排序的性能比之前更容易預測。請注意，Torque還在不停的迭代中，除了編譯到CSA以外，它可能會在將來支持編譯到TurboFan，容許JIT去編譯用Torque編寫的代碼。

微基準測試

在咱們着手開發Array＃sort以前，咱們添加了一系列不一樣的微基準測試，以便更好地瞭解重寫對性能的影響。第一個圖顯示了使用用戶提供的比較函數對各類ElementsKinds進行排序的「正常」用例。

請注意，在這些狀況下，JIT編譯器會作不少工做，由於排序過程幾乎就是咱們（引擎）所處理的。雖然這樣容許咱們在編譯器內聯JavaScript版本中的比較函數，但在Torque中也會有內置函數到JavaScript的額外調用開銷。不過，咱們新的Timsort幾乎在全部狀況下都表現得更好。

下一個圖表顯示了：在處理已徹底排序的數組，或者具備已單向排序的子序列的數組時，Timsort對性能的影響。下圖中採用Quicksort做爲基線，展現了Timsort的加速比（在「DownDown」的狀況下高達17倍，這個場景中數組由兩個反向排序的子序列組成）。能夠看出，除了在隨機數據的狀況下，Timsort在其它全部狀況下都表現得更好，即便咱們排序的對象是PACKED_SMI_ELEMENTS（Quicksort在上圖的微基準測試中對這種對象排序時，性能賽過了Timsort）。

Web 工具基準測試

Web Tooling Benchmark是在Web開發人員經常使用工具的JS環境載體（如Babel和TypeScript）中進行的測試。下圖採用JavaScript Quicksort做爲基線，展現了Timsort的速度提高。除了 chai 咱們在幾乎全部測試中得到了相同的性能。

chai的基準測試中將三分之一的時間用於一個比較函數中（字符串長度計算）。基準測試用的是chai自身的測試套件。因爲數據的緣由，Timsort在這種狀況下須要更多的比較，這對總體的運行有着很大的影響，由於大部分時間都花在了特定的比較函數中。

內存影響

在瀏覽大約50個站點（分別在移動設備和桌面設備上）分析V8堆的快照時，沒有顯示出任何內存消耗的增長或減小。一方面這很讓人意外：從Quicksort到Timsort的轉換引入了對合並run操做所須要的臨時數組的空間，這應該會比Quicksort用於採樣的臨時數組大得多。另外一方面，其實這些臨時數組的存續時間很是短暫（僅在sort調用的持續時間內）而且能夠在V8的新空間中很是快速地建立和刪除。

結論

總的來講，對於在Torque中實現的Timsort的算法屬性和可預測的性能，讓咱們感受很好。Timsort從V8 v7.0和Chrome 70開始生效。快樂排序吧！

做者： Simon Zünd (@nimODota), consistent comparator.