[ccache] Caching failed compilations

Andrew Stubbs ams at codesourcery.com
Mon Jul 6 10:39:08 CEST 2015

On 05/07/15 16:47, Joel Rosdahl wrote:
> Hi,
>     I did have a look at how feasible it is, and basically I think it
>     can be done.
> Yes, caching failures (from the compiler, not the preprocessor) would be
> feasible and I think that it's a good idea, at least as an optional feature.
> I'm not very tempted to add a new kind of file for storing the exit code
> in the cache, though.

I certainly agree that it's not appropriate to have an "exit code: 0" 
file for every successful compile.

I'd also suggest that having a separate file hold error exit codes would 
be confusing should a compile fail (due to out-of-memory, say) and then 
a subsequent run succeeds and is cached (using CCACHE_RECACHE),
and having every cache-miss have to check for, and maybe delete another 
file is only going to hurt performance more.

After thinking further, I'd be tempted to say that ccache should *not* 
cache failures with exit codes other than "1" as they're likely not 
repeatable (OOM, Crtl-C, etc.).

Perhaps just signal a failed compile with a cache result that is present 
but zero-length? (We could also say that it failed if the the binary 
cache is missing, but the stderr cache is present, but that might be 

> Instead I think that we should switch to store
> only one file per result in the cache (except the manifest) and store
> everything (exit code, stderr, object file, dependency file, etc.) in
> it. The downside would be that hard_link mode wouldn't be possible
> anymore but the upside is that fewer i-nodes will be used, which should
> improve performance in theory. (Today at least two i-nodes are used per
> cached result plus one for the manifest.)

Sorry, I don't see any advantage in this scheme. You might save a few 
bytes of disk space, and maybe a few inodes, but I've not seen any 
evidence that those are a problem. You'll also add extra file copies to 
every cache miss, and those are already expensive enough.

If you do go this route, please consider using an open format, like tar, 
and turn on compression by default to offset the internal padding (if 
the benchmarks don't show it hurting).


More information about the ccache mailing list