本節書摘來自異步社群《python算法教程》一書中的第1章，第1.2節，作者[挪威]magnus lie hetland（赫特蘭）， 淩傑 譯，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
當我們在工作中使用算法時，通常都是希望能更有效地解決問題、使程式運作得更快，并且讓解決方案變得更為簡短。但實際情況如何呢？我們獲得所需要的效率、速度和簡潔性了嗎？為什麼人們在使用python這種語言時依然要在乎這些事呢？選擇這種語言對于追求高速度的人來說是一個好的開端嗎？為什麼不選擇c或java這樣的語言呢？
首先，可能是因為python語言本身很讨人喜歡，以至于人們不想換别的語言，或者他們目前也沒有更好的選擇。但最為重要的可能還是第二點，即在這裡，算法設計者們首先要擔心的并不是常數級别的性能差異。 即便相關程式完成任務所需要的時間是另一程式的兩倍，甚至十倍，但這樣的速度可能依然是夠快的。況且，那個較慢的程式（或語言）中可能恰好有某些我們所需要的特性，如它可能有更好的可讀性。而調整和優化程式在很多時候會非常費勁，其代價是不容小視的。然而，無論選擇什麼語言，我們都得考慮一下程式自身的彈性問題。也就是說，如果我們将程式的輸入量翻倍，會發生什麼呢？程式運作時間會是之前的兩倍？四倍？還是更多？或者即便增加那麼一丁點的輸入量也會導緻程式運作時間的成倍增長？當您遇到的問題足夠大的時候，這樣的性能差異顯然就不能再靠簡單的語言選擇或硬體選擇來解決了。在面對一個“足夠大”的問題（在某些情況下，當問題還沒有特别大的時候，它就已經“足夠大”了）時，我們能抑制運作時間增長的主要武器就隻有——您猜對了——一份紮實的算法設計功底了。
下面讓我們來做一個小小的實驗，打開python的互動解釋器，并輸入以下内容：
乍看這段代碼似乎沒什麼用處，它隻是簡單地将一堆數字添加到一個（最初為）空清單中，然後反轉該清單而已。但在更現實的情況下，這些數字很可能是來自某些外部資料源（如它們可能是對一台伺服器建立的連接配接），而或許是為了實作最近優先的原則，我們希望這些數字被添加到清單中後順序是相反的。于是我們産生了一個想法：與其到最後才将整個清單反轉過來，何不在數字出現的時候就将它插到清單的頭部？這樣的話，我們可以将相關代碼精簡如下（還是同樣的解釋器視窗）：
除非我們以前遇到過類似的情況，否則一定會覺得這段新代碼看上去很不錯。但如果您有機會去試一試的話，就會發現其實速度反而是明顯變慢了。至少在我的計算機上，第二段代碼完成任務所需的時間大約是第一段的200倍。而且不僅是速度變慢了，其應對問題規模的性能彈性也更差了。我們不妨來測試一下，如将變量count的值由105增加到106。不出所料的話，第一段代碼的運作時間應該大約比原來增長了十倍……但第二版的速度則是下降了兩個數量級，即它竟比第一版慢了兩千倍以上！讀者可能已經猜到了，随着問題的規模持續擴大，這兩個版本之間的差距隻會越來越大。這時候，我們的選擇就會比任何時候都要來得重要。
請注意：