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 _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
