Ccache 编译缓存靠谱吗？它根据什么条件判断是否命中缓存？

[mikewang]

公司里 C++代码越来越多，修改一处代码，之后编译时间需要耗费十分钟以上。
由于编译过程是 一堆 Shell 脚本 + 各种 Makefile ，依赖错综复杂，不能直接利用 make 的增量编译。

我看中了 Ccache （ https://ccache.dev ），它可以伪装成 G++ 编译器，调用真正的 G++ 并将结果缓存至 ~/.ccache 。Ccache 遇到同样的编译后，直接返回缓存结果加快编译速度。

实测 Ccache 可以将这些代码编译时间压缩到两分钟。然而，我更关心 Ccache 是怎么判断代码未被更改，命中缓存的。
已知 Makefile 根据文件修改时间判断代码未被更改，这个感觉不太靠谱，而且 git 切到其他分支再回来，修改时间就变了。

所以判断代码是否更新这一点还是很重要的，做的不好会有以下副作用：

1. 判断条件不够精确，未更新当作更新了，缓存命中率低，慢；
2. 判断条件不够精确，更新了当作未更新，使用缓存，编译结果不正确；
3. 判断条件过于苛刻，全文 checksum 过慢，起不到加速效果。

其中最担心的是第二点，更新了代码却使用缓存，那就不靠谱了。
有使用过 Ccache 的兄弟们欢迎交流～

感谢大家～

查文档 ✘
看代码 ✘
问Ｖ友 ✔ 😏

其实也是顺带宣传一下 Ccache ，它真的是太快了

[Monad]

印象里是预处理之后的文件内容。

[missdeer]

第 3 点不用担心，再慢也不会慢于 C++编译。scons 好像就是通过 md5 文件内容来判断的。

[learningman]

https://github.com/ccache/ccache/blob/master/src/ccache.cpp#L1191-L1270

代码又不多，自己找找呗。。。

[datocp]

最近一直在编绎 openwrt ，对于大多数包都是有加速的，但是 openwrt 是先 clean 再 complie 遇到 mac80211 时间就相当长，感觉重新来了一遍。

[datocp]

主要是 mac80211 又拆成各种不同功能的 ipk 。

[waruqi]

大多数时候都是稳定的，原理就是根据预处理后的代码，计算 hash 来缓存 object file ，用于加速二次编译。

因为如果你代码没怎么改动，预处理的速度 一般比编译快很多，即使 rebuild 也能很快过掉。

你也可以尝试 xmake ，内置了 cache 机制，跨编译器和平台，完全不依赖 ccache 。编译非常快。

[heiher]

https://ccache.dev/manual/latest.html#_how_ccache_works

[superares]

https://github.com/mozilla/sccache
这个试过么

[lixile]

Ccache 生效机制还跟底层文件系统有干涉（此处特指 zfs ，准确的说 truenas 上的 zfs ）
一般来说 ccache 在 ci cd 领域是大量采用的，可以放心使用，另外如果宿主机的内存够大，可以切分部分内存出来作为 cache 的存储目录
另外 cache 可能需要定期清理，以保证良好的命中率，避免加速效果衰弱

[ac23]

腾讯开源了一个 yadcc ，老哥可以调研调研，不过只支持 linux 平台

[my3157]

clang-13 编译, 没缓存 8c16g vm 编译大概 105 min 左右, 加了 ccache, 大部分时候 15-30 min 就跑完了 , 提到的三点都没遇到, 反而由于 ccache 版本太低, 只支持按照文件大小逐出缓存, 高版本好像支持 ttl 了

[lance0loong]

目前已经在在生产环境中使用近一年,没出现过缓存错误问题.而缓冲机制靠的是,最后调用 gcc 或者 g++的参数和内容进行 cache.如果出现编译标记修订或者文件修订,将会重新编译,所以在使用 ccache 时,避免频繁修改编译标记.