带有着色的DFS需要O(V+E) vs联合查找需要O(ElogV)
参考：http://www.geeksforgeeks.org/detect-cycle-undirected-graph/
因此，联合查找方法较慢。 如果V = 100，E = 100，DFS = 200，则Union find为1,000。 是否有理由使用Union找到？我个人喜欢它，因为它产生一个干净的代码。 或者我错过了什么联盟发现在实际操作中更好？
答案 0 :(得分：3)
与path compression和union by rank的联盟查找将具有O(E*α(n))复杂度，其中α(n)是反Ackermann function。它的运行时间与DFS相当，但就个人而言，我会使用DFS，它更简单，更明显地完成任务。
我更喜欢union-find的唯一理由是当我们将一些无序列表/边缘集合作为图形表示时，我们不能或不想使用额外的时间/内存来为DFS转换此数据。
答案 1 :(得分：2)
我怀疑你可能会错误地解释大O符号的工作原理。符号O（V + E）并不意味着“运行时是通过添加V和E来计算的”，而是“运行时根据V和E的总和进行计算。”例如，假设您运行DFS在具有1,000个节点和1,000个边缘的图形上，运行时间为1ms。然后可以合理地假设具有2,000个节点和2,000个边缘的图形上的运行时间类似于2ms。但是，大O符号本身不会如果你没有建立一些参考点，告诉你某些给定输入的运行时是什么。我在这里给出的1ms数字是一个完全猜测 - 你必须运行实现来看看你得到的运行时。
类似地，运行时O（E log V）表示“运行时缩放为节点数和边数的对数的乘积。”例如，如果运行时输入具有1,000个节点和1,000如果边缘是1ms，那么具有1,000个节点和2,000个边缘的输入上的运行时可能是2ms，并且具有1,000,000个节点和1,000个边缘的输入上的运行时同样大约为2ms。再次，找出运行时的唯一方法将在一些初始输入上运行它，看看会发生什么。
另一个细节 - 正如许多其他人所指出的那样，联合查找数据结构给出的绑定是一个非常低效的联合查找结构。使用具有路径压缩和逐级联合的不相交集合林，您可以获得每个操作的O（α（n））的渐近运行时间，其中α（n）是一个非常缓慢增长的函数（阿克曼反函数）对于你可以适应宇宙的所有输入，这基本上是5。
有了这样的说法 - DFS的渐近运行时优于union-find方法，因此在实践中它可能是更快的。 DFS也相对容易实现，所以我建议采用这种方法。
union-find结构的优点在于它可以连续添加边缘的连接问题的增量版本.DFS不能很好地处理这种情况。