[ccache] Ccache's use of preprocessed source
ams at codesourcery.com
Mon Dec 2 04:40:43 MST 2013
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
> - 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
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 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.
More information about the ccache