複雜度分析:如何分析、統計演算法的執行效率和資源消耗
作者:京東物流 崔旭
我們都知道,資料結構和演算法本身解決的是“快”和“省”的問題,即如何讓程式碼執行得更快,如何讓程式碼更省儲存空間。所以,執行效率是演算法一個非常重要的考量指標。那如何來衡量你編寫的演算法程式碼的執行效率呢?這裡就要用到我們今天要講的內容:時間、空間複雜度分析。
1 為什麼需要複雜度分析?
你可能會有些疑惑,我把程式碼跑一遍,通過統計、監控,就能得到演算法執行的時間和佔用的記憶體大小。為什麼還要做時間、空間複雜度分析呢?這種分析方法能比實實在在跑一遍得到的資料更準確嗎?
首先可以肯定地說,這種評估演算法執行效率的方法是正確的。很多資料結構和演算法書籍還給這種方法起了一個名字,叫事後統計法。但是,這種統計方法有非常大的侷限性。
1.1 測試結果非常依賴測試環境
測試環境中硬體的不同會對測試結果有很大的影響。比如,我們拿同樣一段程式碼,分別用 Intel Core i9 處理器和 Intel Core i3 處理器來執行,i9 處理器要比 i3 處理器執行的速度快很多。還有,比如原本在這臺機器上 a 程式碼執行的速度比 b 程式碼要快,等我們換到另一臺機器上時,可能會有截然相反的結果。
1.2 測試結果受資料規模的影響很大
對同一個排序演算法,待排序資料的有序度不一樣,排序的執行時間就會有很大的差別。極端情況下,如果資料已經是有序的,那排序演算法不需要做任何操作,執行時間就會非常短。除此之外,如果測試資料規模太小,測試結果可能無法真實地反應演算法的效能。比如,對於小規模的資料排序,插入排序可能反倒會比快速排序要快!
所以,我們需要一個不用具體的測試資料來測試,就可以粗略地估計演算法的執行效率的方法,這就是我們接下來要說的大O複雜度表示法。
2 大O複雜度表示法
演算法的執行效率,粗略地講,就是演算法程式碼執行的時間。但是,如何在不執行程式碼的情況下,用“肉眼”得到一段程式碼的執行時間呢?
這裡有段非常簡單的程式碼,求 1,2,3…n 的累加和。現在,一塊來估算一下這段程式碼的執行時間吧。
從 CPU 的角度來看,這段程式碼的每一行都執行著類似的操作:讀資料-運算-寫資料。儘管每行程式碼對應的 CPU 執行的個數、執行的時間都不一樣,但是,我們這裡只是粗略估計,所以可以假設每行程式碼執行的時間都一樣,為 unit_time。在這個假設的基礎之上,這段程式碼的總執行時間是多少呢?
第 2、3 行程式碼分別需要 1 個 unit_time 的執行時間,第 4、5 行都運行了 n 遍,所以需要 2n_unit_time 的執行時間,所以這段程式碼總的執行時間就是 (2n+2)_unit_time。可以看出來,所有程式碼的執行時間 T(n) 與每行程式碼的執行次數成正比。
按照這個分析思路,我們再來看這段程式碼。
我們依舊假設每個語句的執行時間是 unit_time。那這段程式碼的總執行時間 T(n) 是多少呢?
第 2、3、4 行程式碼,每行都需要 1 個 unit_time 的執行時間,第 5、6 行程式碼迴圈執行了 n 遍,需要 2n_unit_time 的執行時間,第 7、8 行程式碼迴圈執行了 n²遍,所以需要 2n²_unit_time 的執行時間。所以,整段程式碼總的執行時間 T(n) = (2n²+2n+3)*unit_time。
儘管我們不知道 unit_time 的具體值,但是通過這兩段程式碼執行時間的推導過程,我們可以得到一個非常重要的規律,那就是,所有程式碼的執行時間 T(n) 與每行程式碼的執行次數 n 成正比。我們可以把這個規律總結成一個公式。注意,大 O 就要登場了!
我來具體解釋一下這個公式。其中,T(n) 我們已經講過了,它表示程式碼執行的時間;n 表示資料規模的大小;f(n) 表示每行程式碼執行的次數總和。因為這是一個公式,所以用 f(n) 來表示。公式中的 O,表示程式碼的執行時間 T(n) 與 f(n) 表示式成正比。
所以,第一個例子中的 T(n) = O(2n+2),第二個例子中的 T(n) = (2n²+2n+3)。這就是大O時間複雜度表示法。大O時間複雜度實際上並不具體表示程式碼真正的執行時間,而是表示程式碼執行時間隨資料規模增長的變化趨勢,所以,也叫作漸進時間複雜度,簡稱時間複雜度。
當 n 很大時,你可以把它想象成 10000、100000。而公式中的低階、常量、係數三部分並不左右增長趨勢,所以都可以忽略。我們只需要記錄一個最大量級就可以了,如果用大 O 表示法表示剛講的那兩段程式碼的時間複雜度,就可以記為:T(n) = O(n); T(n) = O(n²)。
3 時間複雜度分析
前面介紹了大 O 時間複雜度的由來和表示方法。現在我們來看下,如何分析一段程式碼的時間複雜度?
3.1 只關注迴圈執行次數最多的一段程式碼
大 O 這種複雜度表示方法只是表示一種變化趨勢。我們通常會忽略掉公式中的常量、低階、係數,只需要記錄一個最大階的量級就可以了。所以,我們在分析一個演算法、一段程式碼的時間複雜度的時候,也只關注迴圈執行次數最多的那一段程式碼就可以了。這段核心程式碼執行次數的 n 的量級,就是整段要分析程式碼的時間複雜度。
為了便於你理解,我還拿前面的例子來說明。
其中第 2、3 行程式碼都是常量級的執行時間,與 n 的大小無關,所以對於複雜度並沒有影響。迴圈執行次數最多的是第 4、5 行程式碼,所以這塊程式碼要重點分析。前面我們也講過,這兩行程式碼被執行了 n 次,所以總的時間複雜度就是 O(n)。
3.2 加法法則:總複雜度等於量級最大的那段程式碼的複雜度
這裡還有一段程式碼。
這個程式碼分為三部分,分別是求 sum_1、sum_2、sum_3。我們可以分別分析每一部分的時間複雜度,然後把它們放到一塊兒,再取一個量級最大的作為整段程式碼的複雜度。
第一段的時間複雜度是多少呢?這段程式碼迴圈執行了 100 次,所以是一個常量的執行時間,跟 n 的規模無關。
即便這段程式碼迴圈 10000 次、100000 次,只要是一個已知的數,跟 n 無關,照樣也是常量級的執行時間。當 n 無限大的時候,就可以忽略。儘管對程式碼的執行時間會有很大影響,但是回到時間複雜度的概念來說,它表示的是一個演算法執行效率與資料規模增長的變化趨勢,所以不管常量的執行時間多大,我們都可以忽略掉。因為它本身對增長趨勢並沒有影響。
那第二段程式碼和第三段程式碼的時間複雜度是多少呢?答案是 O(n) 和 O(n²)。
綜合這三段程式碼的時間複雜度,我們取其中最大的量級。所以,整段程式碼的時間複雜度就為 O(n²)。也就是說:總的時間複雜度就等於量級最大的那段程式碼的時間複雜度。那我們將這個規律抽象成公式就是:
如果 T1(n)=O(f(n)),T2(n)=O(g(n));那麼 T(n)=T1(n)+T2(n)=max(O(f(n)), O(g(n))) =O(max(f(n), g(n))).
3.3 乘法法則:巢狀程式碼的複雜度等於巢狀內外程式碼複雜度的乘積
剛講了一個複雜度分析中的加法法則,這兒還有一個乘法法則。類比一下,你應該能“猜到”公式是什麼樣子的吧?
如果 T1(n)=O(f(n)),T2(n)=O(g(n));那麼 T(n)=T1(n)_T2(n)=O(f(n))_O(g(n))=O(f(n)*g(n)).
也就是說,假設 T1(n) = O(n),T2(n) = O(n²),則 T1(n) * T2(n) = O(n³)。落實到具體的程式碼上,我們可以把乘法法則看成是巢狀迴圈,我舉個例子給你解釋一下。
我們單獨看 cal() 函式。假設 f() 只是一個普通的操作,那第 4~6 行的時間複雜度就是,T1(n) = O(n)。但 f() 函式本身不是一個簡單的操作,它的時間複雜度是 T2(n) = O(n),所以,整個 cal() 函式的時間複雜度就是,T(n) = T1(n)_T2(n) = O(n_n) = O(n²)。
3.4 幾種常見時間複雜度例項分析
雖然程式碼千差萬別,但是常見的複雜度量級並不多。稍微總結了一下,這些複雜度量級幾乎涵蓋了大部分的場景。
- 常量階 O(1)
- 對數階 O(logn)
- 線性階 O(n)
- 線性對數階 O(nlogn)
- 平方階 O(n²)
- 立方階 O(n³) …
- 指數階 O(2ⁿ)
- 階乘階 O(n!)
對於剛羅列的複雜度量級,我們可以粗略地分為兩類,多項式量級和非多項式量級。其中,非多項式量級只有兩個:O(2ⁿ) 和 O(n!)。
當資料規模 n 越來越大時,非多項式量級演算法的執行時間會急劇增加,求解問題的執行時間會無限增長。所以,非多項式時間複雜度的演算法其實是非常低效的演算法。我們主要來看幾種常見的多項式時間複雜度。
1.O(1)
首先你必須明確一個概念,O(1) 只是常量級時間複雜度的一種表示方法,並不是指只執行了一行程式碼。比如這段程式碼,即便有 3 行,它的時間複雜度也是 O(1),而不是 O(3)。
只要程式碼的執行時間不隨 n 的增大而增長,這樣程式碼的時間複雜度我們都記作 O(1)。或者說,一般情況下,只要演算法中不存在迴圈語句、遞迴語句,即使有成千上萬行的程式碼,其時間複雜度也是Ο(1)。
2.O(logn)、O(nlogn)
對數階時間複雜度非常常見,同時也是最難分析的一種時間複雜度。我通過一個例子來說明一下。
根據我們前面講的複雜度分析方法,第三行程式碼是迴圈執行次數最多的。所以,我們只要能計算出這行程式碼被執行了多少次,就能知道整段程式碼的時間複雜度。
從程式碼中可以看出,變數 i 的值從 1 開始取,每迴圈一次就乘以 2。當大於 n 時,迴圈結束。
實際上,變數 i 的取值就是一個等比數列。如果我把它一個一個列出來,就應該是這個樣子的:
所以,我們只要知道 x 值是多少,就知道這行程式碼執行的次數了。通過 2ˣ=n 求解 x ,x=log₂n,所以,這段程式碼的時間複雜度就是 O(log₂n)。
現在,我把程式碼稍微改下,你再看看,這段程式碼的時間複雜度是多少?
根據我剛剛講的思路,很簡單就能看出來,這段程式碼的時間複雜度為 O(log₃n)。
實際上,不管是以 2 為底、以 3 為底,還是以 10 為底,我們可以把所有對數階的時間複雜度都記為 O(logn)。為什麼呢?
我們知道,對數之間是可以互相轉換的,log₃n 就等於 log₃2_log₂n,所以 O(log₃n) = O(C_log₂n),其中 C=log₃2 是一個常量。基於我們前面的一個理論:在採用大 O 標記複雜度的時候,可以忽略係數,即 O(Cf(n)) = O(f(n))。所以,O(log₂n) 就等於 O(log₃n)。因此,在對數階時間複雜度的表示方法裡,我們忽略對數的“底”,統一表示為 O(logn)。
如果你理解了O(logn),那 O(nlogn) 就很容易理解了。還記得我們剛講的乘法法則嗎?如果一段程式碼的時間複雜度是 O(logn),我們迴圈執行 n 遍,時間複雜度就是 O(nlogn) 了。而且,O(nlogn) 也是一種非常常見的演算法時間複雜度。比如,歸併排序、快速排序的時間複雜度都是 O(nlogn)。
3.O(m+n)、O(m*n)
我們再來講一種跟前面都不一樣的時間複雜度,程式碼的複雜度由兩個資料的規模來決定。老規矩,先看程式碼!
從程式碼中可以看出,m 和 n 是表示兩個資料規模。我們無法事先評估 m 和 n 誰的量級大,所以我們在表示複雜度的時候,就不能簡單地利用加法法則,省略掉其中一個。所以,上面程式碼的時間複雜度就是 O(m+n)。
針對這種情況,原來的加法法則就不正確了,我們需要將加法規則改為:T1(m) + T2(n) = O(f(m) + g(n))。但是乘法法則繼續有效:T1(m)_T2(n) = O(f(m)_f(n))。
4 空間複雜度分析
前面,咱們花了很長時間講大 O 表示法和時間複雜度分析,理解了前面講的內容,空間複雜度分析方法學起來就非常簡單了。
時間複雜度的全稱是漸進時間複雜度,表示演算法的執行時間與資料規模之間的增長關係。類比一下,空間複雜度全稱就是漸進空間複雜度,表示演算法的儲存空間與資料規模之間的增長關係。
還是拿具體的例子來說明。
跟時間複雜度分析一樣,我們可以看到,第 2 行程式碼中,我們申請了一個空間儲存變數 i,但是它是常量階的,跟資料規模 n 沒有關係,所以我們可以忽略。第 3 行申請了一個大小為 n 的 int 型別陣列,除此之外,剩下的程式碼都沒有佔用更多的空間,所以整段程式碼的空間複雜度就是 O(n)。
我們常見的空間複雜度就是 O(1)、O(n)、O(n²),像 O(logn)、O(nlogn) 這樣的對數階複雜度平時都用不到。而且,空間複雜度分析比時間複雜度分析要簡單很多。
5 內容小結
複雜度也叫漸進複雜度,包括時間複雜度和空間複雜度,用來分析演算法執行效率與資料規模之間的增長關係,可以粗略地表示,越高階複雜度的演算法,執行效率越低。常見的複雜度並不多,從低階到高階有:O(1)、O(logn)、O(n)、O(nlogn)、O(n²)。
- 應用健康度隱患刨析解決系列之資料庫時區設定
- 對於Vue3和Ts的心得和思考
- 一文詳解擴散模型:DDPM
- zookeeper的Leader選舉原始碼解析
- 一文帶你搞懂如何優化慢SQL
- 京東金融Android瘦身探索與實踐
- 微前端框架single-spa子應用載入解析
- cookie時效無限延長方案
- 聊聊前端效能指標那些事兒
- Spring竟然可以建立“重複”名稱的bean?—一次專案中存在多個bean名稱重複問題的排查
- 京東金融Android瘦身探索與實踐
- Spring原始碼核心剖析
- 深入淺出RPC服務 | 不同層的網路協議
- 安全測試之探索windows遊戲掃雷
- 關於資料庫分庫分表的一點想法
- 對於Vue3和Ts的心得和思考
- Bitmap、RoaringBitmap原理分析
- 京東小程式CI工具實踐
- 測試用例設計指南
- 當你對 redis 說你中意的女孩是 Mia