Your performance deteriorates when using recursion because calling a method, in any language, implies a lot of preparation: the calling code posts a return address, call parameters, some other context information such as processor registers might be saved somewhere, and at return time the called method posts a return value which is then retrieved by the caller, and any context information that was previously saved will be restored. the performance diff between an iterative and a recursive approach lies in the time these operations take.

从实现的角度来看，当处理调用上下文所需的时间与执行方法所需的时间相当时，您才真正开始注意到差异。如果递归方法的执行时间比调用上下文管理部分要长，那么就采用递归方法，因为代码通常更易于阅读和理解，而且不会注意到性能损失。否则，出于效率考虑，可以进行迭代。

在很多情况下，它提供了比迭代方法更优雅的解决方案，常见的例子是遍历二叉树，所以它不一定更难维护。一般来说，迭代版本通常更快一些(在优化过程中可能会取代递归版本)，但递归版本更容易理解和正确实现。

递归?从哪里开始呢，维基会告诉你"这是以一种自相似的方式重复项目的过程"

在我做C语言的时候，c++的递归是上帝的恩赐，就像“尾递归”。您还会发现许多排序算法使用递归。快速排序示例:http://alienryderflex.com/quicksort/

递归就像任何其他算法一样，适用于特定的问题。也许你不能马上或经常找到一个用途，但会有问题，你会很高兴它可用。

递归比迭代的任何可能定义都更简单(因此也更基本)。你可以只用一对组合子定义一个图灵完备系统(是的，在这样的系统中，甚至递归本身也是一个衍生概念)。Lambda演算是一个同样强大的基本系统，具有递归函数。但是如果你想正确地定义一个迭代，你需要更多的原语来开始。

至于代码——不，递归代码实际上比纯迭代代码更容易理解和维护，因为大多数数据结构都是递归的。当然，为了正确使用它，至少需要一种支持高阶函数和闭包的语言，以简洁的方式获得所有标准的组合子和迭代器。当然，在c++中，复杂的递归解决方案可能看起来有点丑，除非你是fc++的铁杆用户。

使用递归，每次“迭代”都会产生函数调用的成本，而使用循环，你通常只需要支付递增/递减的代价。因此，如果循环的代码并不比递归解决方案的代码复杂多少，循环通常会优于递归。

把它写成递归，或者作为练习，可能会很有趣。

但是，如果要在生产中使用该代码，则需要考虑堆栈溢出的可能性。

尾递归优化可以消除堆栈溢出，但是您是否想要经历这样的麻烦，并且您需要知道您可以指望它在您的环境中进行优化。

每次算法递归，数据大小或n减少了多少?

If you are reducing the size of data or n by half every time you recurse, then in general you don't need to worry about stack overflow. Say, if it needs to be 4,000 level deep or 10,000 level deep for the program to stack overflow, then your data size need to be roughly 24000 for your program to stack overflow. To put that into perspective, a biggest storage device recently can hold 261 bytes, and if you have 261 of such devices, you are only dealing with 2122 data size. If you are looking at all the atoms in the universe, it is estimated that it may be less than 284. If you need to deal with all the data in the universe and their states for every millisecond since the birth of the universe estimated to be 14 billion years ago, it may only be 2153. So if your program can handle 24000 units of data or n, you can handle all data in the universe and the program will not stack overflow. If you don't need to deal with numbers that are as big as 24000 (a 4000-bit integer), then in general you don't need to worry about stack overflow.

但是，如果每次递归时都将数据或n的大小减小一个常数，那么当n仅变为20000时，就会遇到堆栈溢出。也就是说，当n为1000时，程序运行良好，你认为程序很好，然后在未来的某个时候，当n为5000或20000时，程序堆栈溢出。

所以如果你有堆栈溢出的可能，试着让它成为一个迭代的解决方案。