【发布时间】:2014-09-05 04:27:03
【问题描述】:
在很多地方,我都看到使用堆栈实现快速排序比使用递归更快的说法。这是真的?我知道编译器通常擅长将递归更改为迭代,但是链接到页面上的 cmets 声称它太复杂而无法优化。
快速排序还有哪些其他优化?
以下是一些我认为迭代实现优于递归实现的地方: http://www.geeksforgeeks.org/iterative-quick-sort/
尽管进行了上述优化,该函数仍然是递归的并使用 函数调用堆栈来存储 l 和 h 的中间值。这 函数调用堆栈将其他簿记信息与 参数。此外,函数调用涉及存储等开销 调用函数的激活记录,然后恢复执行。
上面的函数可以很容易地转换为迭代版本 辅助堆栈的帮助。
Quicksort : Iterative or Recursive
我了解到递归算法总是比他们的算法慢 迭代对应。
然而,答案指出这并不总是正确的,尽管我不明白为什么要为将函数状态存储在系统堆栈上所涉及的开销提出论点。
使用显式堆栈和迭代代替递归实现的优势本质上是三个方面:
http://www.codeproject.com/Articles/23196/Iterative-Quick-Sort
Using an explicit stack allows the sort to avoid the temporary storage of unnecessary information. Rather than placing two partitions on a stack in arbitrary order, as a typical recursive Quicksort would implicitly do, the sizes of the首先检查分区,指针指示较大的 两者是堆叠的。较小分区的指针未堆叠 完全:我们能够做到这一点,因为我们可以保证较小的 partition 总是等价于第二个递归调用, 它位于函数的末尾。这导致第三 优势: 任何尾端递归都可以消除并用一个简单的循环替换。
由于递归,它不会扩展:JVM 没有尾调用 优化,它只会将方法调用堆栈增加到某些东西 与要排序的数组成正比,并且它会因太大而失败 大批。 (甚至对于确实有尾调用的语言/平台 优化我认为他们无法将其实际应用于此 代码)
还有很多基于堆栈/迭代的快速排序实现 here,但我猜编码人员这样做只是为了好玩?
【问题讨论】:
-
你的基准测试告诉你什么?
-
比较苹果和橘子?你不是说迭代还是递归?
-
@MarkRansom 我的大脑告诉我,这是一种将基准测试留给后者并给出一些理论思考的情况,然后再随意散列代码并将其撞到基准测试器中。
-
@leppie 我认为迭代快速排序确实实现了堆栈,所以从这个意义上说是的。
标签: optimization recursion quicksort