TA貢獻1864條經驗 獲得超6個贊
這取決于使用的語言。你寫了'語言不可知'，所以我舉一些例子。
在Java，C和Python中，與迭代（通常）相比，遞歸相當昂貴，因為它需要分配新的堆棧幀。在某些C編譯器中，可以使用編譯器標志來消除此開銷，這會將某些類型的遞歸（實際上是某些類型的尾調用）轉換為跳轉而不是函數調用。
在函數式編程語言實現中，有時，迭代可能非常昂貴，并且遞歸可能非常便宜。在許多情況下，遞歸轉換為簡單的跳轉，但是更改循環變量（這是可變的）有時需要一些相對繁重的操作，尤其是在支持多個執行線程的實現上。由于mutator和垃圾收集器之間的交互，如果兩者可能同時運行，在某些環境中突變是昂貴的。
我知道在一些Scheme實現中，遞歸通常比循環更快。
簡而言之，答案取決于代碼和實現。使用您喜歡的任何風格。如果您使用的是函數式語言，則遞歸可能會更快。如果您使用命令式語言，迭代可能會更快。在某些環境中，這兩種方法都會導致生成相同的程序集（將其放入管道并對其進行抽吸）。
附錄：在某些環境中，最好的選擇既不是遞歸也不是迭代，而是高階函數。這些包括“map”，“filter”和“reduce”（也稱為“fold”）。這些不僅是首選樣式，不僅通常更清晰，而且在某些環境中，這些函數是第一個（或唯一）從自動并行化中獲得提升的功能 - 因此它們可以比迭代或遞歸快得多。Data Parallel Haskell就是這種環境的一個例子。
列表推導是另一種選擇，但這些通常只是迭代，遞歸或更高階函數的語法糖。
TA貢獻1891條經驗 獲得超3個贊
如果替代方法是顯式管理堆棧，遞歸可能會更快，就像您提到的排序或二叉樹算法一樣。
我有一個案例，用Java重寫遞歸算法使它變慢。
因此，正確的方法是首先以最自然的方式編寫它，只有在分析顯示它是關鍵的時候進行優化，然后測量所謂的改進。
舉報