正在阅读接受的答案问题的定位与查找：用法、彼此的优缺点这表明它locate的主要优点是速度，我想做一些测试，看看我是否可以从它的使用中受益。
我的第一步是估计find工具在提供类似服务时的速度locate（因此仅搜索文件名，没有额外内容）。
我很惊讶地看到
time find / 2>/dev/null >/dev/null
我假设迭代所有文件（取决于用户权限），显示
real 0m1.231s
user 0m0.353s
sys 0m0.867s
相当快的结果。
我的问题是应用的命令是否是实际基准速度的一种方法find？
我有兴趣回答的问题的一个方面是，文件系统中是否存在某种缓冲区，因此在操作系统（Linux 内核）中是否存在某种缓冲区，这会影响结果？
我的结果是，通过删除缓存echo 3 > /proc/sys/vm/drop_caches，大大提高了速度find：
$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"
$ time (find / 2>/dev/null >/dev/null)
real 0m24.290s
user 0m1.143s
sys 0m8.230s
然而在我的 Linux 系统上，后续使用find恢复到mlocate大约 1 秒的速度？
总结一下，我有兴趣知道一种对 find 命令进行基准测试的方法（与locate 进行比较）
更新/备注
虽然这个问题是由另一个比较引起的，locate并且find我询问测量/基准测试的速度，但find我知道从实时操作系统/文件系统（即find）收集的数据不太可能比数据库中的查找更快查找（即locate）。由于我的操作系统内核具有相当好的缓存行为，我通过find或进行搜索的执行时间仍然相当相似locate。
因此，问题归结为是否足以删除操作系统（文件系统）缓存，以模拟find冷启动时完成所需的“实际”时间，以及假设这些速度增强缓存持续存在有多现实（与数据库文件相似updatedb locate）用于所有后续find调用。
答案1
在 OpenBSD 上，定位数据库默认每周重建一次/etc/weekly/usr/libexec/locate.updatedb以 user身份调用脚本nobody。
这locate.updatedb实用程序是一个或多或少在根文件系统上运行的/bin/sh脚本（在 OpenBSD 上）。任何可以访问的内容都会放入定位数据库中。pdkshfindnobody
我发现很难相信这find /会比使用通过 . 创建的文件数据库的locate系统更快。locatefind /
当然，区别在于你可能会发现更多文件find通过以比该用户具有更高访问权限的用户身份运行nobody。
在 Linux 上，至少在我工作时可以访问的 Ubuntu 机器上，locate根据手册，数据库似乎每天都会重新创建locate(8)。这是通过updatedb实用程序完成的。
该实用程序（本机上的符号链接/usr/bin/updatedb.mlocate）是属于 包 的已编译二进制文件mlocate。
你可以看看的来源mlocate如果您愿意的话，但它基本上是一个遍历文件系统的 C 程序。 mlocate还尝试避免遍历运行之间未更改的文件系统位。
同样，我发现很难相信查询mlocate数据库会比运行慢（在任何情况下）find /。
归根结底，这就是为什么所有locate工具（我所知道的）都针对数据库工作的原因。