嵌套循环与递归固定高度树答案

【问题标题】：Nested for loops versus Recursion for fixed height Tree嵌套循环与递归固定高度树
【发布时间】：2014-04-17 07:08:44
【问题描述】：

我知道这是基本的计算机科学问题，我的问题可能匹配的是this。

但它没有涵盖我的 web 应用程序中的两种不同场景。

我正在处理两个不同的树状对象数组，它们以children 作为成员。现在

具有固定高度的第一棵树（最多 3 层）
第二棵树，具有任意级别深度。

两棵树的结构类似于下面（它是一个对象数组，基本上是一个 JSON）：

0 ---- someKey
|
---- someOtherKey
|
---- children
                0 ---- someKey
                |
                ---- someOtherKey
                |
                ---- children
                              0 ---- someKey
                              |
                              ---- someOtherKey
                              |
                              ---- children []
                1 ---- someKey
                |
                ---- someOtherKey
                |
                ---- children []

1 ---- someKey
|
---- someOtherKey
|
---- children []

2 ---- someKey
|
---- someOtherKey
|
---- children []

现在要遍历第一棵树，我使用 3 个嵌套的 for 循环，而对于第二个，我使用递归来访问每个节点直到叶子。到目前为止，我的表现还算公平。

但是在第一种情况下使用递归有什么好处吗？

或

如果第二棵树的深度可变，递归在哪里会不足？

【问题讨论】：

标签： javascript recursion tree iteration

【解决方案1】：

在第一种情况下，递归比循环更糟糕，优缺点取决于编程语言和实现。
循环比递归更好，因为它执行简单的条件检查和跳转，其中递归涉及压入堆栈帧、跳转、返回和从堆栈中弹出。
在第二种情况下，需要递归，因为我们确实知道树的深度，所以我们不能在代码中放置那么多循环。

【讨论】：

对于第二种情况，树的深度是不确定的，我正在进行尾递归调用以访问树的每个节点（因此不会担心超出调用堆栈）但是这里关注的是在第一种情况下使用递归方法，保证树最多有 3 层嵌套。
你可以不使用递归而是使用我们自己的堆栈实现遍历here link
所以不会出现'堆栈调用超出'的问题
问题不在这两种方法中，我正在寻找强有力的理由来为我使用嵌套循环的第一个案例重写代码，并将其转换为递归，以便我可以共享相同在不影响性能的情况下在两个地方遍历树的代码。（我正在处理一棵树中约 5000 个或以上的节点）。
所以使用我们自己的堆栈但没有递归的第二种方法。原因很简单，树的深度不固定

【解决方案2】：

对于任何一种情况，您都可以使用任何一种方法。递归将为您提供更简单的代码，更易于维护和阅读。可能会有性能成本，但这可能不会很大，特别是如果您能够使用尾递归。从递归开始可能是个好主意，然后仅在以下情况下才转移到循环：(i) 需要更好的性能和 (ii) 使用循环时可衡量的性能改进。

【讨论】：