Red*_*Red 49 performance find dolphin
我正在尝试查找我的主目录和所有子目录中不存在的文件。
find ~/ -name "bogus"几秒钟后给我这些信息，但KDE 的dolphin文件管理器需要将近 3 分钟才能做到这一点。这与我之前使用GNOME 的beagle经验相符。
find当图形搜索（使用起来比命令行参数更直观）落后时，如何设法快速地做同样的事情？
Gil*_*il' 71
特别使用 Baloo 来查看 Dolphin，它似乎在其搜索域中查找每个文件的元数据，即使您正在执行简单的文件名搜索。当我跟踪file.so过程中，我看到了电话lstat，getxattr并getxattr再次为每个文件，甚至对于..条目。这些系统调用检索有关文件的元数据，该文件存储在与文件名不同的位置（文件名存储在目录内容中，但元数据在inode 中）。多次查询文件的元数据很便宜，因为数据将在磁盘缓存中，但查询元数据和不查询元数据之间可能存在显着差异。
find更聪明。它试图避免不必要的系统调用。它不会调用，getxattr因为它不会基于扩展属性进行搜索。当它遍历一个目录时，它可能需要调用lstat不匹配的文件名，因为这可能是一个递归搜索的子目录（lstat是系统调用，它返回文件元数据，包括文件类型，例如常规/目录/符号链接/...）。但是find有一个优化：它从它的链接计数中知道一个目录有多少个子目录，lstat一旦它知道它遍历了所有子目录，它就会停止调用。特别是在叶目录（没有子目录的目录）中，find只检查名称，不检查元数据。此外，某些文件系统在目录条目中保留文件类型的副本，因此如果这是它需要的唯一信息，find则甚至不需要调用lstat。
如果您find使用需要检查元数据的选项运行，它将进行更多lstat调用，但lstat如果不需要信息，它仍然不会调用文件（例如，因为文件被先前的条件排除在外）名称匹配）。
我怀疑其他重新发明find轮子的GUI 搜索工具同样不如经过数十年优化的命令行实用程序聪明。至少，如果您搜索“无处不在”，Dolphin 足够聪明，可以使用定位数据库（在 UI 中并不清楚结果可能已过时的限制）。