深度优先搜索是搜索文件系统的一种可怕方式 - 实际上，可能位于非常靠近根目录的文件下可能需要很长时间才能找到DFS，因为DFS会分散注意力另一个深刻的，无关的目录层次结构 但是，它的资源需求非常好 - 它需要保持打开的文件句柄数量只与层次结构的深度成比例，而不是它的大小。
广度优先搜索是一个明显的解决方案 - 它非常快 （上次测量时，它与我系统上的DFS大约相同，约为8秒。）
然而BFS有其自身的问题 - BFS需要保持打开非常大量的目录句柄，可能有数百万。 （在我的系统上，它大约有100,000个手柄，这是非常高的。它可能更容易。）
这导致了几个问题：
保持打开这么多句柄不仅消耗内存（无论如何相对便宜），还包括许多其他类型的资源，例如虚拟文件系统内的文件句柄（网络，安装目录等），以及可能是其他有限的内核级资源。
它还会给用户带来其他实际问题：例如，一个保持打开的虚拟目录不再可以关闭！这意味着，例如，用户可能无法关闭程序，弹出某些设备或关闭某种外部连接。这种方法可能会产生各种各样的问题。
这似乎是迭代加深，然后是解决方案。
问题？这在实践中非常缓慢 我遇到的麻烦是大型目录（例如Windows中的WinSxS）为每个深度级别重新枚举 ，即使它们不需要。我最后一次尝试这个时，迭代加深比我系统上的DFS慢了〜15倍。因此，8秒的搜索大约需要120秒左右，这是不可接受的。
当然，试图跟踪你不应该打开的目录（也许是因为你注意到你不再需要打开它们）通过揭示我们所有的资源问题而首先破坏了使用迭代深化的目的和BFS一起。
所以，问题很简单：
如果您正在搜索您不熟悉的文件系统，您应该如何在速度和可用性之间实现可接受的平衡？有比BFS更好的选择吗？
答案 0 :(得分：4)
如果您对文件的位置没有任何指导，那么我认为您无法做很多事情。你应该尽量减少寻求并用一些技巧寻找时间，但是文件系统变得支离破碎，你无法知道这一点，所以在那里做很多事情很难。在搜索子目录之前搜索目录中的文件应该在很多文件系统上更快，特别是如果您正在寻找可能已经内联的小文件。使用完整的BFS不会耗尽内核资源也是一件好事。
即使您只提示文件的位置，也可以提供很多帮助。例如，如果它是用户放置的文件然后忘记了位置，则从主目录，临时目录和驱动器的根开始，并执行DFS到合理的递归限制（例如，6- 8可以在我的Windows或OS X机器上找到任何手动放置的文件或自动下载的文件）理论上用户通常不会意外地得到深树，但自动生成的层次结构可能会变深。如果该搜索失败，请返回并搜索您之前跳过的深层目录。如果文件 丢失，则搜索速度会变慢，因此请回到DFS以确保安全，并且在用户继续使用本机时不会造成太多问题。
最重要的是，如果系统有任何类型的搜索索引，请首先检查，即使这意味着要编写更多代码来支持它。