演算法和資料結構

演算法和資料結構

演算法和資料結構——千絲萬縷的聯絡

縱觀各種演算法書籍，大多都是將演算法和資料結構作為一個整體來講述。

資料結構就是陣列、樹結構等儲存或表現物件資料的結構。

將演算法和資料結構作為整體講述，是因為必須依照演算法中的常用操作選擇資料結構。例如，事先將資料儲存在適當的樹形結構中，大多數情況下搜尋會變得很簡單，可以降低複雜度。

第11課中已經看到，RDBMS的索引的實現採用了B+樹這種樹結構。B+樹是個空間上適合外部儲存的樹結構。利用B+樹儲存索引，不僅能減少查詢所需的操作步驟，還能將磁碟讀取次數降至最低。因此，RDBMS的索引一般採用B+樹，同時使用適合該資料結構的演算法進行查詢、插入、排序等操作。

所以說，演算法和資料結構之間存在著千絲萬縷的聯絡。

演算法和資料結構

資料結構

陣列、樹結構、堆……

根據演算法常用操作進行選擇

要根據演算法常用操作來選擇資料結構

複雜度和常數項——評測很重要

計算量的複雜度記法忽略了所有“常數項”。所謂常數項就是演算法實現中不依賴於輸入大小，但卻不得不執行的一類處理。

例如函式呼叫、函式返回等處理都是常數項，第一次分配變數、if語句分支等也是常數項。簡單的實現中，常數項幾乎不會影響演算法的複雜度，但在複雜的實現中，常數項就不可忽略了。就算實現不復雜，CPU快取是否容易生效、分支預測是否發生等計算機結構特點也會有影響，因此常數項可能會導致差距。

例如，例如排序演算法的理論下限為O(n log n)，有幾個演算法的平均複雜度能達到O(n log n)。但是，同為O(n log n)，一般而言快速排序是最快的。快速排序的特點使得CPU快取容易生效，這一點比其他演算法好得多。這就是常數項較小的例子。

也就是說，複雜度記法適用於比較演算法，但在實現時不應只考慮複雜度。而且常數項經常取決於實現方法，因此實現時要盡力減小常數項。

實現時要注意的最佳化問題

另一方面希望大家注意，實現某樣東西（不僅限於演算法）時，一開始就對常數項進行最佳化，基本上是錯誤的。努力減少複雜度為O(n²)的演算法的常數項，還不如用O(n log n)的演算法來代替，那樣改善效果更好。

說來說去，還是“評測最重要”。透過評測（benchmark）或分析（profiling）等手段，正確找出當前程式的問題所在最為重要。是要更換演算法來改善，還是減少常數項來改善，或者是物理資源不足要更換硬體以改善效能？務必在認真找出問題所在之後，再設法改善。

本文節選自《大規模WEB服務開發技術》一書

圖書詳細資訊:http://space.itpub.net/?uid-13164110-action-viewspace-itemid-705176