V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ldm0  ›  全部回复第 1 页 / 共 6 页
回复总数  101
1  2  3  4  5  6  
2 天前
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@nbook 感谢反馈,我研究下怎么处理
2 天前
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@hkhk366 欢迎切磋~ 一些感受意见:

1. 搜索我看你用的 jwalk-meta ( https://github.com/brmmm3/jwalk-meta ),本身也是也是一个不错的实现,速度和 Cardinal 的 fswalk 是一个量级的:我的电脑上 773 万个文件索引完花费 29 秒钟
2. 4 毫秒是个非常棒的速度! Cardinal 在 773 万个文件上的全盘搜索速度是 56 毫秒。这其中的主要差别我猜测主要在于文件 metadata 获取和本地 ipc ,Cardinal 会将这两部分包含在搜索耗时之中。
3. 没有找到你的 FSEvent 获取逻辑,可能会在第一次扫描之后索引逐渐过时。

欢迎下载 Cardinal 进行一些横向对比,包括 CPU 占用内存占用,以及功能的丰富程度。欢迎交流~ :D
2 天前
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@EdgarZhang 新的版本已经增加搜索白名单~
2025 年 12 月 15 日
回复了 SmaliYu 创建的主题 问与答 想适配 Google 的 16K PageSize,但担心旧的设备会崩溃
16K page size 只是相比 4K 更严格的内存对齐标准,满足 16K 对齐的肯定也满足 4K 对齐,不会影响兼容性。
2025 年 11 月 14 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@devoteever 不太了解怎么集成。
优势是更快,更准,更全(刚刚下载横向对比了一下)。
2025 年 11 月 13 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@Vaspike `full disk access` 在这里的原因是要遍历索引整个文件系统,文件搜索工具都需要这个 level 的权限。
不可能不申请(
2025 年 11 月 10 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@theo 试试最新版呢,修复了一个索引卡死的 bug https://github.com/ldm0/cardinal/releases/
2025 年 11 月 8 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
正常百万级的文件索引是在 10 秒内完成的。
索引逻辑是并行遍历文件系统(主要是 readdir),可能是访问某个文件夹阻塞了。
主要问题在于我这边的几台机器,包括我朋友同事的机器索引都比较快无法复现这个问题,目前没有什么头绪。

@xxnemesis1 @prudence @rainfox 有联系方式么,我可以单独出个 debug 包看看什么文件访问卡住了。我的 WX 是 TERNMjMzMzMzMw==
2025 年 11 月 8 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
2025 年 11 月 7 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@rainfox 我现在手上没有 Intel 的机器,不好测试。我找个虚拟机看看
2025 年 11 月 7 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@clementewy 可以~晚上下完班加一手
2025 年 11 月 7 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@Heanes 由于 APFS 的 lstat 接口太慢了(被 NTFS 暴打),没有办法在构建索引时全量获取文件 metadata 。如果苹果不优化的话,没有办法全量排序。因此折中提供了一个 events panel (里面有最新更新的文件列表)

但是搜索结果的排序我会加下(比如搜索结果小于 1w 个时可以根据 path/mtime/ctime 排序),这个在 todo list 上。
2025 年 11 月 7 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@duxiansen https://github.com/ldm0/cardinal/releases/tag/v0.1.1 发了个新版,可以再试试看~
2025 年 11 月 7 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@duxiansen 这个我操作一手。检索 iCloud 应该不会下载(因为只是 readdir),应该是缩略图获取才会触发。

这个我用 OneDrive 的时候发现了类似的情况,之前在代码里加了判断。我本地测试一下 iCloud 。
2025 年 11 月 7 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
@Mangozhen
> 这个功能我真的离不开。因为很多时候我都是靠记忆的关键词来检索很久没用的文档。这也是为什么我至今一直使用的 Spotlight ,而没有使用其它类似的工具。

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

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

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

因为面向的需求不一样,所以形态和实现都会有差别~
2025 年 11 月 7 日
回复了 ldm0 创建的主题 分享创造 Cardinal: macOS 的快速文件搜索(已开源)
感谢反馈~
> 初始化要的时间比较长,我这边大约 400 万个文件,花费了差不多 45 分钟来建立索引;
这个还比较奇怪,正常不会有这么慢,我的电脑 700 万个文件应该是 11 秒索引完。有插存储卡之类的东西嘛。
> 当前版本似乎不支持后台运行。推出后立即进入,会卡顿一下(大约是更新索引)。
是加载磁盘里的缓存。
> 特别想要能够自动进行关键词匹配,而不是完全匹配搜索。
是说分词+模糊匹配嘛
2025 年 9 月 24 日
回复了 ldm0 创建的主题 macOS macOS Tahoe R 角千层面
@x4gz 确实,终端和 Instruments 是一样的 R 角
2022 年 6 月 21 日
回复了 ldm0 创建的主题 分享创造 [音频分离] Spleeter 的 Rust 实现
@ufan0 Thanks!

我也是开发呀 :D ,我们这边的工作时间比较弹性,一般是 10 9 5 。
这个也是业余时间写的。
飞书
2022 年 4 月 10 日
回复了 echojoy 创建的主题 问与答 大家的主语言都是什么啊,为什么选择他(她)
因为快乐选择 Rust
1  2  3  4  5  6  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5605 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 25ms · UTC 03:17 · PVG 11:17 · LAX 19:17 · JFK 22:17
♥ Do have faith in what you're doing.