睡眠分类的时间复杂度是多less？
鉴于这种algorithm，你如何expression它的时间复杂性？
最初在这里介绍 （部分存档） 。
#!/bin/bash function f() { sleep "$1" echo "$1" } while [ -n "$1" ] do f "$1" & shift done wait example usage: ./sleepsort.bash 5 3 6 3 6 3 1 4 7 O(max(input)+n)
复杂性似乎难以expression，因为大多数sortingalgorithm是数据不可知的。 他们的时间与数据量有关，而不是数据本身。
正如在这里指出的那样，FWIW对于sorting数据并不是一个可靠的algorithm。
似乎没有人提到的一点是如何实施这些sleep 。 最终，他们最终在一个调度程序的地方，操作的复杂性将取决于所使用的调度algorithm。 例如，如果将sleep s作为事件放在优先级队列中，则最终可能会得到相当于堆sorting的东西，其复杂度为O（n log n） 。 天真的调度algorithm可能会导致O（n ^ 2） 。
我认为paxdiablo是最近的，但不是正确的原因。 时间复杂度忽略了实际硬件上的问题，如高速caching大小，内存限制以及在这种情况下进程的有限数量和调度程序的操作。
基于维基百科页面的时间复杂性，我会说，答案是，你不能确定运行时的复杂性，因为如果它被定义为：
时间复杂度通常通过计算algorithm执行的基本操作的数量来估计，其中基本操作需要固定的时间量来执行。 因此，algorithm所花费的时间量和基本操作的数量最多相差一个常数。
那么我们就不能谈论这个algorithm的运行时复杂度，因为基本操作所花费的时间差别很大，所花费的时间相差不止一个常数。
algorithm的时间复杂度和stream程复杂度都是O(braindead) 。
在数据集中有足够大的值 ，您将等待答案，直到太阳爆炸。
有了足够大的数据集大小，你会的
- （1）打到你的程序限制; 和
- （2）发现在早期的睡眠开始之前，早期的睡眠将完成，这意味着集合
(2,9,9,9,9,9,...,9,9,1)将不能正确地分类1和2。
在这种情况下时间复杂性是无关紧要的。 你不能得到比“错误”更less的优化。
可以使用复杂性分析来比较algorithm，因为数据集大小是变化的，但是当algorithm首先是可笑的时候不行。
如果你读了这个主题，你会发现你的问题已经被回答了。 时间复杂度为O(max(input)) ，操作复杂度（操作数）为O(n) 。
虽然看起来像线性，但我认为复杂度仍然是O（log（n）* max（input））。
当我们谈论渐近时间复杂度时，意味着当n增长无限大时需要多less时间。
基于比较的sortingalgorithm不能比O（n * log（n））快，并且睡眠sorting实际上是基于比较的：
进程睡眠n秒钟并唤醒。 操作系统需要从所有睡眠过程中find最less的睡眠时间，如果时间到了，就将其唤醒。
这将需要一个优先级队列，这需要O（logN）时间插入一个元素，O（1）find最小元素，O（logN）删除最小元素。
当n变得非常大时，唤醒一个进程需要花费1秒以上的时间，这使得它比O（n）大。
我和乔丹在一起，除了我认为挂钟时间的复杂性更好地表示为O（2 ^ m），其中m是每个项目的大小，而不是O（max（input））。
如果每个项目的大小为m，则最大项目将具有2 ^ m的整数值（减1，但是没有人关心）。 通过构build，该algorithm要求build立时间小于1，一个常数。
所以挂钟时间复杂度为O（2 ^ m），操作数复杂度为O（n）。
考虑到build立时间的改进algorithm可能具有壁时钟时间复杂度O（2 ^ m + n）。 例如，它可以在开始时logging当前时间，计算base_time = start_time + k*len(list) （对于某个适当的常量k），然后使线程hibernate直到时间base_time+i 。 那么k*len(list)显然是O（n），而i是O（2 ^ m），总共为O（2 ^ m + n）。
