在本文中，我們將探討 “二次方” 和 “n log(n)” 等術(shù)語(yǔ)在算法中的含義。

[[314140]]

在后面的例子中，我將引用這兩個(gè)數(shù)組，一個(gè)包含 5 個(gè)元素，另一個(gè)包含 50 個(gè)元素。我還會(huì)用到 JavaScript 中方便的 performance API 來(lái)衡量執(zhí)行時(shí)間的差異。

const smArr = [5, 3, 2, 35, 2]; 
 
const bigArr = [5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2]; 

什么是 Big O 符號(hào)?

Big O 表示法是用來(lái)表示隨著數(shù)據(jù)集的增加，計(jì)算任務(wù)難度總體增長(zhǎng)的一種方式。盡管還有其他表示法，但通常 big O 表示法是最常用的，因?yàn)樗塾谧顗牡那闆r，更容易量化和考慮。最壞的情況意味著完成任務(wù)需要最多的操作次數(shù);如果你在一秒鐘內(nèi)就能恢復(fù)打亂魔方，那么你只擰了一圈的話，不能說(shuō)自己是做得最好的。

當(dāng)你進(jìn)一步了解算法時(shí)，就會(huì)發(fā)現(xiàn)這非常有用，因?yàn)樵诶斫膺@種關(guān)系的同時(shí)去編寫(xiě)代碼，就能知道時(shí)間都花在了什么地方。

當(dāng)你了解更多有關(guān) Big O 表示法的信息時(shí)，可能會(huì)看到下圖中不同的變化。我們希望將復(fù)雜度保持在盡可能低的水平，最好避免超過(guò) O(n)。

O(1)

這是理想的情況，無(wú)論有多少個(gè)項(xiàng)目，不管是一個(gè)還是一百萬(wàn)個(gè)，完成的時(shí)間量都將保持不變。執(zhí)行單個(gè)操作的大多數(shù)操作都是 O(1)。把數(shù)據(jù)寫(xiě)到數(shù)組、在特定索引處獲取項(xiàng)目、添加子元素等都將會(huì)花費(fèi)相同的時(shí)間量，這與數(shù)組的長(zhǎng)度無(wú)關(guān)。

const a1 = performance.now(); 
smArr.push(27); 
const a2 = performance.now(); 
console.log(`Time: ${a2 - a1}`); // Less than 1 Millisecond 
 
 
const b1 = performance.now(); 
bigArr.push(27); 
const b2 = performance.now(); 
console.log(`Time: ${b2 - b1}`); // Less than 1 Millisecond 

O(n)

在默認(rèn)情況下，所有的循環(huán)都是線性增長(zhǎng)的，因?yàn)閿?shù)據(jù)的大小和完成的時(shí)間之間存在一對(duì)一的關(guān)系。所以如果你有 1,000 個(gè)數(shù)組項(xiàng)，將會(huì)花費(fèi)的 1,000 倍時(shí)間。

const a1 = performance.now(); 
smArr.forEach(item => console.log(item)); 
const a2 = performance.now(); 
console.log(`Time: ${a2 - a1}`); // 3 Milliseconds 
 
const b1 = performance.now(); 
bigArr.forEach(item => console.log(item)); 
const b2 = performance.now(); 
console.log(`Time: ${b2 - b1}`); // 13 Milliseconds 

O(n^2)

指數(shù)增長(zhǎng)是一個(gè)陷阱，我們都掉進(jìn)去過(guò)。你是否需要為數(shù)組中的每個(gè)項(xiàng)目找到匹配對(duì)?將循環(huán)放入循環(huán)中是一種很好的方式，可以把 1000 個(gè)項(xiàng)目的數(shù)組變成一百萬(wàn)個(gè)操作搜索，這將會(huì)使你的瀏覽器失去響應(yīng)。與使用雙重嵌套循環(huán)進(jìn)行一百萬(wàn)次操作相比，最好在兩個(gè)單獨(dú)的循環(huán)中進(jìn)行 2,000 次操作。

const a1 = performance.now(); 
smArr.forEach(() => { 
    arr2.forEach(item => console.log(item)); 
}); 
const a2 = performance.now(); 
console.log(`Time: ${a2 - a1}`); // 8 Milliseconds 
 
 
const b1 = performance.now(); 
bigArr.forEach(() => { 
    arr2.forEach(item => console.log(item)); 
}); 
const b2 = performance.now(); 
console.log(`Time: ${b2 - b1}`); // 307 Milliseconds 

O(log n)

我認(rèn)為關(guān)于對(duì)數(shù)增長(zhǎng)比較好的比喻，是想象在字典中查找像 “notation” 之類(lèi)的單詞。你不會(huì)在一個(gè)詞條一個(gè)詞條的去進(jìn)行搜索，而是先找到 “N” 這一部分，然后是 “OPQ” 這一頁(yè)，然后按字母順序搜索列表直到找到匹配項(xiàng)。

通過(guò)這種“分而治之”的方法，找到某些內(nèi)容的時(shí)間仍然會(huì)因字典的大小而改變，但遠(yuǎn)不及 O(n) 。因?yàn)樗鼤?huì)在不查看大部分?jǐn)?shù)據(jù)的情況下逐步搜索更具體的部分，所以搜索一千個(gè)項(xiàng)目可能需要少于 10 個(gè)操作，而一百萬(wàn)個(gè)項(xiàng)目可能需要少于 20 個(gè)操作，這使你的效率最大化。

在這個(gè)例子中，我們可以做一個(gè)簡(jiǎn)單的 快速排序。

const sort = arr => { 
  if (arr.length < 2) return arr; 
 
  let pivot = arr[0]; 
  let left = []; 
  let right = []; 
 
  for (let i = 1, total = arr.length; i < total; i++) { 
    if (arr[i] < pivot) left.push(arr[i]); 
    else right.push(arr[i]); 
  }; 
  return [ 
    ...sort(left), 
    pivot, 
    ...sort(right) 
  ]; 
}; 
sort(smArr); // 0 Milliseconds 
sort(bigArr); // 1 Millisecond 

O(n!)

最糟糕的一種可能性是析因增長(zhǎng)。最經(jīng)典的例子就是旅行的推銷(xiāo)員問(wèn)題。如果你要在很多距離不同的城市之間旅行，如何找到在所有城市之間返回起點(diǎn)的最短路線?暴力方法將是檢查每個(gè)城市之間所有可能的路線距離，這是一個(gè)階乘并且很快就會(huì)失控。

由于這個(gè)問(wèn)題很快會(huì)變得非常復(fù)雜，因此我們將通過(guò)簡(jiǎn)短的遞歸函數(shù)演示這種復(fù)雜性。這個(gè)函數(shù)會(huì)將一個(gè)數(shù)字去乘以函數(shù)自己，然后將數(shù)字減去1。階乘中的每個(gè)數(shù)字都會(huì)這樣計(jì)算，直到為 0，并且每個(gè)遞歸層都會(huì)把其乘積添加到原始數(shù)字中。

階乘只是從 1 開(kāi)始直至該數(shù)字的乘積。那么 6!是 1x2x3x4x5x6 = 720。

const factorial = n => { 
  let num = n; 
 
  if (n === 0) return 1 
  for (let i = 0; i < n; i++) { 
    num = n * factorial(n - 1); 
  }; 
 
  return num; 
}; 
factorial(1); // 2 Milliseconds 
factorial(5); // 3 Milliseconds 
factorial(10); // 85 Milliseconds 
factorial(12); //  11,942 Milliseconds 

我原本打算顯示 factorial(15)，但是 12 以上的值都太多，并且使頁(yè)面崩潰了，這也證明了為什么需要避免這種情況。

結(jié)束語(yǔ)

我們需要編寫(xiě)高性能的代碼似乎是一個(gè)不爭(zhēng)得事實(shí)，但是我敢肯定，幾乎每個(gè)開(kāi)發(fā)人員都創(chuàng)建過(guò)至少兩重甚至三重嵌套循環(huán)，因?yàn)?ldquo;它確實(shí)有效”。Big O 表示法在表達(dá)和考慮復(fù)雜性方面是非常必要的，這是我們從未有過(guò)的方式。