1樓：抽轉組
對於碰枝遞迴，有人提到了兩點：
1）對棧的容量的壓力。
2）個別問題的遞迴解法，其演算法的低效性。
這兩個因素我簡短點評下，1）對棧的容量壓力：
通常遞迴的深笑握敏度很大造成的。對於這一點當然應該有程式設計師編碼時，來衡量和把握。win32 中乙個新建的執行緒，預設的棧通常在 1 mb 大小。
那麼如果你的遞迴函式，深度很大，顯然程式設計師應該對這種情況有預估，和對風險的避免。
這就和你選擇，把記憶體分配在棧上還是堆上，會考慮到分配的記憶體大小的因素一樣。
當然，如果在函式內分配很大的棧上空間，在函式體內定義乙個很大的陣列，這樣不需要很深的深度，也會讓棧溢位。這當然也是程式設計師自己應該控制的。
2）個別問題的遞迴解法，演算法的低效。
這個低效主要在於這個問題的演算法本身。而不是在遞迴這種方法上。比如說求斐波那契的某一項，子問題會大量重複出現，會產生很多重複計算，這個是很多演算法書上，是用來引匯出動態規劃或者查表法的。
這主要是演算法本身的效率問題，而不是遞迴的問題。這一點是必須應該明確的。
3）我們可以看到，在和樹有關的演算法中，經常會有遞迴函式。
例如，遍歷資料夾，刪除登錄檔的某乙個 key （及其所有子key）。
尤其對一般樹的前序，後序遍歷，二叉樹的中序遍歷。
這主要原因是因為樹的定義，就皮慶是「遞迴性」的：
樹就是，某乙個節點有多個子節點，每個子節點是乙個樹。
我們再此可以看到，遞迴的顯著優點，是對解的描述的直觀性，**的簡潔性。<>
2樓：網友
之前做 rapidjson 時，直譯器用遞迴下降方式，由於沒有限定層數，有機會做極深的 json 請求來引發 stack overflow（如 "[一百萬層），產生安全性及穩定性問題。
之後同事再寫多了乙個版本，就是自行實現 stack （所謂的用迭代取代遞迴），只要有足夠的 heap 就不會有問題。當然，在這個個例上，也可以簡單地限制層數來解決。
遞迴的額外耗蠢雹沒時決於函式呼叫的成本，這成本與具體平臺相關。
許多時候，可以尾呼叫的遞迴還不如顯式寫作迭代。不可以尾呼叫的遞迴，要換作迭代方式就需要自建 stack，較為複雜，但有可能降低時間和空間的係數，並且能支援更大的深度。
遞迴效率低是函式呼叫的開銷導致的。
在乙個函式呼叫之前需要做許多工作，比如準備函式內區域性變數使用的空間、搞定函式的引數等等，這些事情每次呼叫函式都需要做，因此會產生額外開銷導致遞迴效率偏低，所以邏輯上開銷一致時遞迴的額外開銷會多一些。
當然了，通過有意識的組織**的寫法可以把某些遞迴寫成尾遞迴，尾遞迴可以進肆中行特殊的優化所以效率會比普通的遞迴高一些，也不會因為遞迴太多導致棧溢位。
遍歷樹還不用遞迴的話，那麼人肉寫乙個棧+深度優先遍歷或者人肉佇列+廣度優先遍歷，再輔以黑魔法給棧或者佇列提速，應該會比遞迴快一些，加速幅度和語言和寫法相關，但在大多數情況下我覺得是得不償失的，帶納花了很大精力很可能效率提公升不明顯<>
遞迴演算法的速度會特別慢的原因是什麼？
3樓：
遞迴呼叫本身需要使用系統棧，每次分配函式記憶體以及棧都需要時間。不過這個過程耗時並不多，可以說，單純的遞迴本身並不比非遞迴慢多少。
然而，實踐中就會發現，遞迴處理部分問題，特別是遞推類問題時會表現出效率極低。這個問題的出現是因為重複計算。
舉例說，用遞迴求解斐波那契數列的第n項，一般的遞迴公式為。
f(n) = f(n-1)+f(n-2)
f(2) = 1
f(1) = 1
請嘗試模擬計算機執行這個遞迴，你會發現，其中的某一項f(x)並不是只算了一次。當你計算f(5)的時候，你會試圖計算f(4)和f(3),然而在你計算f(4)的時候其實也要計算f(3),這樣f(3)就被呼叫了兩次。
想象這個過程是指數型擴充套件的，效率會隨著n的增大極快地下降。
要解決這個問題，可以使用記憶化思想。
定義記憶陣列r,函式體改為：
define f(n):
if r[n] is defined, then simply return r[n] as the answer.
else, f(n) = f(n-1) +f(n-2)
before return the value, take it down in r[n].
如此改進之後的遞迴函式效率上與遞推演算法相差無幾。
4樓：翎
主要有兩個原因吧。
1、遞迴需要不斷的向下開棧，相較於迴圈，開銷自然上來了，開棧的開銷主要表現在：需要向棧上壓引數（即訪存，一般的**會儘可能使用暫存器進行運算），需要往棧上壓函式返回位址，需要給區域性變數準備空間。
2、棧保護機制，因為現代編譯器為了防止各種溢位攻擊，會給函式呼叫加上棧保護，對應到指令層次就是會往棧上壓乙個金絲雀值。
所以一般追求效率的地方都會把遞迴改成迴圈，或者手動模擬棧。
5樓：網友
之前做 rapidjson 時，直譯器用遞迴下降方式，由於沒有限定層數，有機會做極深的 json 請求來引發 stack overflow（如 "[一百萬層），產生安全性及穩定性問題。
之後同事再寫多了乙個版本，就是自行實現 stack （所謂的用迭代取代遞迴），只要有足夠的 heap 就不會有問題。當然，在這個個例上，也可以簡單地限制層數來解決。
遞迴的額外耗時決於函式呼叫的成本，這成本與具體平臺相關。
許多時候，可以尾呼叫的遞迴還不如顯式寫作迭代。不可以尾呼叫的遞迴，要換作迭拍孫代方式就需要自建 stack，較為複雜，但有可能降低時間和空間的係數，並且能支援更大的深度。
遞迴效率低是函式呼叫的開銷導致的。
在乙個函式呼叫之前需要做許多工作，比如準備函式內兆賀輪區域性變數使用的空間、搞定函式的引數等等，這些事情每次呼叫函式都需要做，因此會產生額外開銷導致遞迴效率偏低，所以邏輯上開銷一致時遞迴的額外開銷會多一些。
當然了，通過有意識的組織**的寫法可以把某些遞迴寫成尾遞迴，尾遞迴族信可以進行特殊的優化所以效率會比普通的遞迴高一些，也不會因為遞迴太多導致棧溢位。
遍歷樹還不用遞迴的話，那麼人肉寫乙個棧+深度優先遍歷或者人肉佇列+廣度優先遍歷，再輔以黑魔法給棧或者佇列提速，應該會比遞迴快一些，加速幅度和語言和寫法相關，但在大多數情況下我覺得是得不償失的，花了很大精力很可能效率提公升不明顯。
為什麼公平比效率更重要為什麼說效率比公平更重要？
以道德為依據，公平會調動人的積極性，產生強大的凝聚力和向心力，提高效率。當個人被認同，在心理上會產生知遇之心，使其想盡辦法提高工作效率，公平與效率相協調，使社會保持穩定的秩序和穩定的發展 注重效率，維護公平既是精神文明建設和思想道德建設的應有之義，也是社會主義建設的本質要求，它反映了社會主義市場經濟...
國外工作效率低為什麼還那麼發達，為什麼你的工作效率比別人低？
首先糾正一下，並不是所有的外國都是發達國家，還有很多極其落後的國家，例如索馬利亞，烏干達，非洲大部分國家。以美國為首的西方國家之所以發達除了他們重視教育和當時 採取的措施得當外，他們當初都是通過戰爭和掠奪得到了第一桶金，並且目前美國還在用金融手段掠奪其他國家的財富。大家都說外國發達其實這種觀點在幾十...
執行中脫硫效率低的原因是什麼,影響脫硫效率的原因有哪些處理的方法是什麼
影響脫硫效率的因素主要有 1 裝置的影響 煙氣流速 液氣內比 2 煙氣 的容影響 煙氣流量 煙氣so2含量 煙氣溫度 煙氣中飛灰 cl離子等 3 脫硫劑的影響 石灰石的品質 純度 磨製粒徑等 4 執行引數控制的影響 吸收塔的ph值 加入漿液量 氧化空氣量 鈣硫比 5 其他影響 工藝水質 測量儀表等....