你不知道的JS系列——領略性能測試與調優

---

這個世界沒有什麼好畏懼的，反正咱們只來一次

說明

學習總結 + 我的理解，鞏固 + 方便查閱，你們願意看的簡單看看就好

木桶效應 & 約束理論

木桶效應: 一隻木桶能盛多少水，並不取決於最長的那塊木板，而是取決於最短的那塊木板。也可稱爲短板效應。
約束理論: 一個系統最薄弱的地方肯定了這個系統有多強大，專一於瓶頸。與直覺相反，若是你把整個系統分解，單獨優化每一個部分，你會下降整個系統的效率。相反，要優化整個系統。

類比咱們人類，人無完人，誰都有缺點，缺點越多成功的概率就越小，咱們想要成功就須要先改善缺點，要改善缺點前提就是先要找到缺點。那麼對於系統而言，就是經過性能測試定位系統短板，而後進行鍼對性調優。各類各樣的系統，只能說這個系統更適合哪方面，不適合哪方面，你總不能拿 B2B 系統去作 C2C 方面的業務，既然是作 B2B 的系統，那針對這個系統你就該在 B2B 方面去針對性改善。

---

現實社會殘酷無情，人們老是會變成最初本身討厭的模樣

---

性能測試

如題: 如何測試某個運算的速度（即執行時間）?
答:

var start = Date.now();
doSomething();  // 進行一些操做
var end = Date.now(); 
console.log( "耗時:", (end - start) );
複製代碼

或者：

console.time('A');  // A 爲計時器名稱
doSomething();  // 進行一些操做
console.timeEnd('A');   // 結束計時器A，程序運行所通過的時間會被自動輸出到控制檯
複製代碼

以上作法的錯誤之處：

1. 不十分精確：舉例，若 0ms < 執行時間 < 15ms，而 IE 早期版本定時器精度只有 15ms，故此時報告時間會是 0
2. 只能聲稱此次特定的運行消耗了大概這麼長時間，由於你並不明確此時引擎或系統有沒有受到什麼影響
3. 在得到 start 或 end 時間戳之間也可能有其餘一些延誤
4. 不明確當前運算測試的環境是否過分優化

提問：你說我不精確，那我用循環讓它運行一百一千甚至更屢次，取平均值，這不就精確了?
答： 依舊不精確，太高或太低的的異常值也能夠影響整個平均值，而後再重複應用，偏差繼續擴散，只會產生更大的欺騙性。並且你還有許多須要考慮的東西：定時器的精度、異常因素、運行環境（桌面瀏覽器、移動設備...）等，再者你須要大量的測試樣本，而後聚集測試結果，誠然這並不簡單。

提問：好吧，我不夠專業，那該怎麼辦？
答: 任何有意義且可靠的性能測試都應該基於統計學上合理的實踐。對於統計學，你瞭解並掌握了多少？
講真: 唉，我只是一個程序員，不懂這些亂七八糟的...
答: 好吧，那就直接用輪子吧，關於這些已經有聰明的人寫好了，這裏提供一個優秀的庫: Benchmark.js，另外你還能夠去 jsPerf 官網看看，它能夠在線分析代碼性能，很是棒。

不要沉迷於微性能

科學研究代表可能大腦能夠處理的最快速度是 13ms，假設這裏有兩個程序 X 和 Y， X 的運算速度是人類大腦捕獲一個獨立的事件發生速度的 125 000 倍，而 Y 只有 100 000 倍，你會以爲 X 比 Y 快不少，但它們的差距在最好狀況下也只是人類大腦所能感知到的最小間隙的 65 萬分之一，因此這些性能差異無所謂，徹底無所謂！

相比之下，咱們更應該關注優化的大局，而不是擔憂這些微觀性能的細微差異（好比 ++a 和 a++ 誰更快）。咱們只須要優化運行在關鍵路徑上的代碼，下面引用的話語足以說明：

花費在優化關鍵路徑上的時間不是浪費，無論節省的時間多麼少；
而花在非關鍵路徑優化上的時間都不值得，無論節省的時間多麼多

儘管程序關鍵路徑上的性能很是重要，但這並非惟一要考慮的因素。在性能方面大致類似的幾個選擇中，可讀性應該是另一個重要的考量因素。
舉 🌰 ：

var x = "42"; // 須要數字42 
// 選擇1：讓隱式類型轉換自動發生
var y = x / 2; 
// 選擇2：使用parseInt(..) 
var y = parseInt( x, 0 ) / 2; 
// 選擇3：使用Number(..) 
var y = Number( x ) / 2; 
// 選擇4：使用一元運算符+ 
var y = +x / 2; 
// 選項5：使用一元運算符| 
var y = (x | 0) / 2;
複製代碼

這裏 parseInt() 與 Number 是函數調用，因此會比較慢，故撇去 1,2,3 ，比較 4 與 5 , 若 5 比 4 快，這點性能也該是微不足道的，此時你亦不應爲了這麼點微性能去選擇 5 而讓程序失去了可讀性。

調優

什麼是尾調用？

尾調用就是一個出如今另外一個函數 "結尾" 處的函數調用，即某個函數的最後一步是調用另外一個函數。這個調用在結束後就沒有其他事情要作了（除了可能要返回結果值）。
舉 🌰 ：

// 正宗尾調用
function f(x){
   return g(x);
}
// 非尾調用，狀況一
function f(x){
   let y = g(x);
   return y;
}
// 非尾調用，狀況二
function f(x){
   return g(x) + 1;
}
// 非尾調用，狀況三
function f(x){
   g(x);
}
複製代碼

狀況一：調用函數 g 以後，還有賦值操做；
狀況二：調用函數 g 以後，還有加操做；
狀況二：調用函數 g 以後，未返回，此時默認爲 return undefined；
以上三種狀況在函數調用後都作了其他的事情，因此都不是尾調用。

尾調用優化（TCO）

先來了解下 調用棧（call stack） 的概念:
call Stack 就是你代碼執行時的地方，定義爲解釋器追蹤函數執行流的一種機制。每調用一個函數，解釋器就會把該函數添加進調用棧並開始執行：

• 若正在調用棧中執行的函數還調用了其它函數，那麼新函數也將會被添加進調用棧，一旦這個函數被調用，便會當即執行。
• 當前函數執行完畢後，解釋器將其清出調用棧，繼續執行當前執行環境下的剩餘的代碼。
• 當分配的調用棧空間被佔滿時，會引起 "堆棧溢出"（stack overflow） 。

JavaScript 是一種單線程編程語言，這意味着它只有一個 Call Stack 。所以，它一次僅能作一件事。

舉個網上常見的 🌰 ：

function multiply(x, y) {
   return x * y;
}
function printSquare(x) {
   var s = multiply(x, x);
   console.log(s);
}
printSquare(5);
複製代碼

函數調用會在內存造成一個 "調用記錄"，又稱 "調用幀"（call frame），保存調用位置和內部變量等信息。全部的調用幀，造成一個 "調用棧"（call stack）。而調用每個新的函數都須要額外的一塊預留內存來管理調用棧，稱爲棧幀。

這裏在函數 printSquare 的內部調用函數 multiply ，那麼在 printSquare 的調用幀上方，會造成一個 multiply 的調用幀。等到 multiply 運行結束，將結果返回到 printSquare， multiply 的調用幀纔會消失。

尾調用因爲是函數的最後一步操做，因此不須要保留外層函數的調用幀，由於調用位置、內部變量等信息都不會再用到了，只要直接用內層函數的調用幀，取代外層函數的調用幀就能夠了。

function foo(x) { 
    return x; 
} 
function bar(y) { 
    return foo(y + 1);  // 尾調用
}
bar(18);
複製代碼

結合上面的例子解釋，也就是說，若是支持 TCO 的引擎可以意識到 foo(y+1) 調用位於尾部，這意味着 bar(..) 基本上已經完成了，那麼在調用 foo(..) 時，foo 的調用幀就能夠直接取代 bar 的調用幀，而且 foo 也不須要建立一個新的棧幀，而是能夠重用已有的 bar(..) 的棧幀。因此上面的代碼就等同於直接調用 foo(19)。

注意： 只有再也不用到外層函數的內部變量，內層函數的調用幀纔會取代外層函數的調用幀，不然就沒法進行「尾調用優化」。
Tips: 內層函數若是須要外層函數的內部變量（特指基本值），此時能夠將這個內部變量做爲內層函數的參數傳入，利用函數參數的按值傳遞特性，這樣內部函數就不會保留對外部函數變量的引用

上述足以體現出尾調用的優點：不只速度更快，也更節省內存。固然在簡單的代碼片斷中，這類優化算不了什麼（我不敢想象將簡單代碼都寫成尾調用的形式，代碼可讀性會有多差），可是在處理遞歸時，這就解決了大問題，特別是若是遞歸可能會致使成百上千個棧幀的時候。有了尾調用優化 （TCO），引擎就能夠用同一個棧幀執行全部這類調用，就永遠不會出現調用棧空間被佔滿致使的 "堆棧溢出"（stack overflow）的狀況。

尾遞歸實現階乘的 🌰 ：

function factorial(n, total = 1) {
    if (n === 1) return total;
    return factorial(n - 1, n * total);
}
factorial(5) // 120
複製代碼

注意：

• ES6 的尾調用優化只在嚴格模式下開啓，正常模式下無效（class內部默認就是嚴格模式）。ES6 還規定要求引擎實現 TCO 而不是將其留給引擎自由決定。
• TCO 只用於有實際的尾調用的狀況。若是你寫了一個沒有尾調用的遞歸函數，那麼性能仍是會回到普通棧幀分配的情形，引擎對這樣的遞歸調用棧的限制也仍然有效。

尾遞歸優化的實現

• 蹦牀函數

function trampoline(f) {
  while (f && f instanceof Function) {
    f = f();
  }
  return f;
}
複製代碼

它接受一個函數 f 做爲參數。只要 f 執行後返回一個函數，就繼續執行（就像蹦牀同樣，一直蹦一直爽😂😂）。

注意： 執行 f 後是返回一個函數，而後再執行該函數，而不是函數裏面調用函數，這樣就避免了遞歸執行，從而就消除了調用棧過大的問題。
原來的遞歸函數須要用 bind改寫：

// sum是一個遞歸函數，參數x是須要累加的值，參數y控制遞歸次數。
function sum(x, y) {
  if (y > 0) {
    return sum.bind(null, x + 1, y - 1); 
    // 這裏用bind將參數傳入並返回函數自己，注意和apply、call不一樣，未當即進行調用，
  } else {
    return x;
  }
}
// 調用
trampoline(sum(1, 100000))
複製代碼

深刻體會一下，調用 sum(1, 100000) 返回傳入了參數的 sum 函數本身自己並做爲參數傳入 trampoline函數內部，trampoline函數內部判斷 sum 存在且是函數就進行調用，再次獲得了傳入了參數的 sum 函數本身自己，並將結果再賦值給 sum 自己，依次循環。這裏邊每循環一次，x 就累加一次，y 遞減一次，從而達到累計的目的。應該注意到這裏面每次循環都是返回一個函數，並無真正意義上發生函數 sum 的執行，只是 sum 的參數在變化，從而避免了大量調用棧的造成。