反向依赖检查速通挑战：以 data.table 为例

nan.xiao

经过一周的 vibe coding、踩坑，和 17 个版本的迭代，上周发布的 Rust CLI 工具 revdeprun 终于可以稳定输出正确的检查结果了…… 这件事能做对的结果没有我想象中的难，但做对的过程比我想象中的难多了 😂

在 data.table 上测试了一下，48 核的 EPYC 7713 检查全部 1723 个反向依赖共使用 8 小时 55 分，可以作为未来速通测试的基准：https://nanx.me/blog/post/revdep-speedrun/

yihui

是的，理论上做对很简单，原理一句话就能说清楚（在新旧版本上各跑一次 R CMD check 再对比结果，确保新版本不冒出新问题），然而落到实际就会有种种意外。当年我写这个 xfun::rev_check() 过程中就是在两种痛苦中挣扎着选一种：是被锐扑厉大人骂，还是把这仿佛看不到尽头的坑挖到底。最终掂量着还是前者更可怕。不过这事做着做着就变成乐趣了，就是眼见着要打的怪物渐渐稀少下来，然后感觉曙光就在眼前、未来在这破事上可以节省大把的时间。到现在我也不确定我写这些代码的时间有没有真的把我“未来”的时间赚回来……唯一能确定的是这个过程确实有很大的成就感。

速度上肯定是还有优化的空间，比如这里就没必要检查每个包是否可加载了（因为都是全新安装的）：https://github.com/yihui/xfun/blob/5fb7285/R/revcheck.R#L127 还有下载源码包也可以并行：https://github.com/yihui/xfun/blob/5fb7285f/R/revcheck.R#L174C10-L174C26 不过这些相对于九个小时的总时长来说可能都只是毛毛雨。我感觉四千多个依赖花了近两个小时才装完可能还有优化空间。

nan.xiao

yihui 那么我又要引用本版版主 @shrektan 的帖子了：高效好用的开发者工具虽然可能无法为开发者本人创造多大价值，但可能可以创造巨大的社会价值。如果一件事情能够能够让自己沉浸其中，那么也说明自己可能真的适合做这件事。

rev_check() 部分的速度已经相当不错了，在规模上去以后没有发现显著的性能瓶颈 👍️ 反观 2 个小时安装二进制包那部分绝对是最大的瓶颈，我认为这件事的合理时间应该压缩进 5 分钟以内。我在文章里也写了，这锅在 pak，正规的解决思路就是像 uv 一样用 Rust 重写 resolver 和 installer。结果有人马上跑过来跟我说他们早就已经按这个思路做了 "rv"，试了一下速度可以，但目前的实现有一些细节问题，暂时无法直接应用，比如无法跳过安装失败的包…… 未来可期。