Re: ccache 4: severe bloat, bulk builds?

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%pkgsrc.org@localhost> writes:

> * On 2026-06-25 at 13:24 BST, Greg Troxel wrote:
>
>>  Is anyone using ccache with bulk builds (bob or pbulk)?  If so, which
>>  ccache version?
>>
>>  How do people feel about the concept?  It seems one often starts over,
>>  and it's good to reuse compilation output, if the inputs matched.
>
> I've never used ccache for full bulk builds.  I should probably put
> some numbers on it at some point, but my intuition says it would
> require a gigantic amount of disk space for minimal gains at best.

I am looking at less than full, to build what I want built, vs
everything, so the size should be much smaller.  I will do an experiment
sometime.

As for size, it should be less than the total uncompressed size of
packages.  But I'll get some numbers.

> I would also worry about the potential for cached objects being used
> when things change either in pkgsrc or on the build host leading to
> very difficult to debug issues, though this may be unfounded.

I get where you're coming from, but I think it's ok.  ccache takes the
hash of the inputs and the compiler, stores that, along with the output.
So when something changes, you get a miss. I see this upgrading many
packages, where all .c files seem to include version.h

And, it's easy to turn it off and rebuild if you suspect it.

The only problems I have ever had were from the stored output getting
corrupted on disk due to hardware/filesystem problems.

> Plus then I have another thing to manage, perform periodic cleanup, etc.

You set the max size and it auto stays under it.  I have been using it
for years and pay very little attention.

> Similar to my feelings on autoswc (especially nervous about false
> positives), I've always tried to focus on more architectural and
> cleaner performance wins rather than resorting to caches.

It's certainly great to work on that side too.  Strictly, this is
memoization not caching, despite the name.  If I do a build of a package
with a security patch, it's nice if most of the c++ work can be skipped.

> I think ccache makes great sense if you're developing a single project
> and do a lot of rebuilds.

I have found it vastly speeds up rolling-replace, in that I typically
see at least 50% hits after an update/build run.  I would expect exactly
the same in bob, as while there's more efficiency, parallelism,
etc. it's basically the same depgraph of compiler invocations.  When you
change one package, you have to rebuild what depends on it (and bob, as
I understand it, is the equivalent of "unsafe_depends_strict", where dep
being rebuilt is cause for rebuilding, even if the version didn't
change).  Those later packages are very likely to have all cache hits,
if the installed headers didn't change (waves hands but supported by
anecdata).




I'm likely going to stop using ccache(4) for now, and do experiments
with 3.