locate（或者更确切地说，updatedb）有点简单：它获取所需路径（通常是“/”）的输出find，对其进行排序，然后使用前置压缩工具（frcode）对其进行压缩，其中连续的公共前缀被替换为重复字符的数量。
所以我想知道，是什么阻止人们为全文搜索创建类似的东西？比如说，串联系统中的每个文件，用格式对每一行进行排序line:filename:linenumber，然后进行前压缩怎么样？我猜你最终会得到一个更快的grep，但代价是在每日/每周 cron 作业运行之前就过时了，就像locate.
也许locategrep对整个系统来说有点杀伤力，但我认为它对于加速一个大型项目很有用，而该项目在一天的剩余时间内不会发生太大变化。
类似的东西是否已经存在或者使用一些已知的工具来实现是微不足道的？
笔记：我宁愿避免包含纯文本搜索之外的功能的企业级解决方案（但我很欣赏正则表达式支持）。
答案1
通常，GNU grep 和 BSD 的竞争速度相当慢。
人们喜欢ag（又名the_silver_searcher）、rg（又名ripgrep）或ack；他们不会尝试建立文本索引，他们只是为每个查询重新搜索它，但以比grep.我rg这些天（主要）使用它，它确实使搜索完整的 Linux 源代码树变得相当容易管理（当我预热文件系统缓存时，“搜索每个文件，即使不是 C 头文件”大约rg FOOBAR需要 3 秒；GNUgrep需要> 10 秒）。
还有全文搜索引擎（主要是 xapian），我将其用作 IMAP 服务器上的插件来加速全文搜索。这是唯一一个被证明对我真正产生影响的用例。
（Ceterum ceneo mandbem esse delendam；我们的搜索工具太快了，需要 30 秒才能重建 190 MB 的手册页索引，这根本不可接受；并且 gzip 是很好的压缩器的想法真的统一的数据，例如手册页，其中有一个压缩字典，可以使这些东西变得非常小，这是我的另一烦恼。但事情相互交织在一起，我无法摆脱 mandb。）