正常百万级的文件索引是在 10 秒内完成的。
索引逻辑是并行遍历文件系统（主要是 readdir)，可能是访问某个文件夹阻塞了。
主要问题在于我这边的几台机器，包括我朋友同事的机器索引都比较快无法复现这个问题，目前没有什么头绪。

@xxnemesis1 @prudence @rainfox 有联系方式么，我可以单独出个 debug 包看看什么文件访问卡住了。我的 WX 是 TERNMjMzMzMzMw==

@xlpxx @rainfox Intel 版本来了~ https://github.com/ldm0/cardinal/releases/tag/v0.1.2

@rainfox 我现在手上没有 Intel 的机器，不好测试。我找个虚拟机看看

@clementewy 可以～晚上下完班加一手

@Heanes 由于 APFS 的 lstat 接口太慢了（被 NTFS 暴打），没有办法在构建索引时全量获取文件 metadata 。如果苹果不优化的话，没有办法全量排序。因此折中提供了一个 events panel （里面有最新更新的文件列表）

但是搜索结果的排序我会加下（比如搜索结果小于 1w 个时可以根据 path/mtime/ctime 排序），这个在 todo list 上。

@duxiansen https://github.com/ldm0/cardinal/releases/tag/v0.1.1 发了个新版，可以再试试看～

@duxiansen 这个我操作一手。检索 iCloud 应该不会下载（因为只是 readdir)，应该是缩略图获取才会触发。

这个我用 OneDrive 的时候发现了类似的情况，之前在代码里加了判断。我本地测试一下 iCloud 。

@Mangozhen
> 这个功能我真的离不开。因为很多时候我都是靠记忆的关键词来检索很久没用的文档。这也是为什么我至今一直使用的 Spotlight ，而没有使用其它类似的工具。

这个软件主要提供了文件路径子串搜索（比如匹配"/Applications/Xcode.app/Contents/Developer" 路径中的 ".app/Contents/Develop"）和正则搜索的支持，这也是 Everything 的最核心功能。

如果要实现分词，搜索的能力感觉就不那么“确定性”了，用起来心里会虚虚的，和设计的初衷有些差别。SpotLight 可能会出现有某个文件但是搜索不到或者搜索不全的情况。Cardinal 和 SpotLight 的最主要差别就是其用起来的感觉是“确定性”的，能搜到就是有，搜不到就是没有。

比如说我开发过程会产生一些细碎文件，SpotLight 在这种场景下更新索引总是不够实时，容易找不到文件，Cardinal 就 100%能找到，只要存在于文件系统上的文件都不会丢失。

因为面向的需求不一样，所以形态和实现都会有差别～

感谢反馈～
> 初始化要的时间比较长，我这边大约 400 万个文件，花费了差不多 45 分钟来建立索引；
这个还比较奇怪，正常不会有这么慢，我的电脑 700 万个文件应该是 11 秒索引完。有插存储卡之类的东西嘛。
> 当前版本似乎不支持后台运行。推出后立即进入，会卡顿一下（大约是更新索引）。
是加载磁盘里的缓存。
> 特别想要能够自动进行关键词匹配，而不是完全匹配搜索。
是说分词+模糊匹配嘛

@x4gz 确实，终端和 Instruments 是一样的 R 角

@ufan0 Thanks!

我也是开发呀 :D ，我们这边的工作时间比较弹性，一般是 10 9 5 。
这个也是业余时间写的。

飞书

因为快乐选择 Rust

资瓷！

谨慎更新，我的 mbp 开不了机了。。。

@2i2Re2PLMaDnghL 完全是这样（
@zagfai 是的，就是在认为这些字串有很大比例重叠的情况下考虑有没有这种压缩算法。

@zagfai 条件是把多个字符串结合成一个字符串，操作之后每一个原字符串都能在最后的大长字符串中以连续子串的形式找到。
@also24 粗浅的看了一下，用了字典之后应该就无法满足连续子串的要求了。
@nvkou 压缩的确有不少已知办法，字典什么的都很高效，但是某些情况就是需要尽可能的压缩字符串，同时也保证能够在内存里面连续出现（比如说如果不连续就经常不能被直接放进语言内置的字符串类型中了）。

CCExtractor?

很强！可以二次开发嘛（