与图形文件搜索实用程序相比，为什么GNU这么快找到？

我正在尝试查找主目录和所有子目录中不存在的文件。

find ~/ -name "bogus"几秒钟后就给我提供了该信息，但是KDE的dolphin文件管理器需要近3分钟来完成相同的操作。这与我以前在GNOMEbeagle上的经验相对应。

如何find能做到同样的速度非常快，而图形搜索（这是更直观的比命令行参数的使用）蛞蝓背后？

特别是使用Baloo查看Dolphin，即使您正在执行简单的文件名搜索，它似乎也在其搜索域中查找每个文件的元数据。当我跟踪该file.so过程时，我看到了对的调用lstat，getxattr并getxattr再次对每个文件甚至..条目进行了调用。这些系统调用检索有关文件的元数据，该元数据与文件名存储在不同的位置（文件名存储在目录内容中，但元数据在inode中）。多次查询文件的元数据是便宜的，因为数据将存储在磁盘缓存中，但是查询元数据和不查询元数据之间可能会有很大的不同。

find更聪明。它试图避免不必要的系统调用。它不会调用，getxattr因为它不会基于扩展属性进行搜索。当遍历目录时，它可能需要调用lstat不匹配的文件名，因为它可能是要递归搜索的子目录（lstat是系统调用，它返回文件元数据，包括文件类型，例如常规/目录/符号链接/…）。但是find有一个优化：它从链接数中知道一个目录有多少个子目录，并且lstat一旦知道遍历所有子目录就停止调用。特别是在叶目录（没有子目录的目录）中，find仅检查名称，不检查元数据。此外，某些文件系统在目录条目中保留文件类型的副本，因此，如果这是唯一需要的信息，find则甚至不需要调用lstat它。

如果find使用需要检查元数据的选项运行，它将进行更多lstat调用，但是lstat如果不需要信息，它仍然不会对文件进行调用（例如，由于先前条件排除了文件，匹配名称）。

我怀疑其他重新发明find轮子的GUI搜索工具比经过数十年优化的命令行实用程序同样不那么聪明。至少，如果您“无处不在”搜索，Dolphin至少足够聪明，可以使用定位数据库（其限制在UI中尚不明确，结果可能已过时）。