[ccache] Ccache's use of preprocessed source

[Andrew Stubbs]

On 29/11/13 16:26, Lubos Lunak wrote:
>   So I think actually CCACHE_CPP2 set is the normal way and _not_ having it set
> can be considered to be a performance hack.

This is an interesting idea. The split preprocess-compile is, indeed, 
the most common pain-point in my experience.

That said, it would very much depend on the numbers; if the performance 
overhead, on cache-miss, is too high then the case for using it is that 
much weaker.

> - how difficult would it be to add a possibility of preventing ccache's use of
> cpp completely, thus relying only on the direct mode? This could be useful in
> case the overhead of CCACHE_CPP2 is considered too big, and possibly even in
> the general case (direct hits should be usually much more common and why have
> the overhead of running cpp for a minority of hits). I could give this a
> shot, but I don't know if there isn't some design problem making this
> difficult/impossible.

Practically impossible: the preprocessor is the means by which ccache 
discovers which source files to hash, so even direct-mode relies on the 
pre-processing on cache-miss. It also provides the means by which ccache 
learns (or rather, doesn't need to learn) the internal configuration of 
the compiler.

The alternative would be to write some sort of custom source-scanner 
(preprocessor by another name) that gives identical results to the 
compiler in every significant sense (include discovery, time-macro 
detection, unique hashability). Of course, if ccache went down that 
route then there some further improvements that could be made (c.f. 
CCACHE_UNIFY), but I very much doubt that the results would be worth the 
effort, and achieving and maintaining 100% compiler compatibility would 
be a tall order.

Andrew