[ccache] Radically different ccache performance on Linux vs OSX
We have a large cross-compilation environment that is essentially identical on both Linux and MacOS X hosts. The build system uses ccache to try to reduce redundant recompilation, but we're seeing radically different outcomes on OSX versus Linux hosts. We're still using ccache 2.4. On Linux hosts, the aggregate performance seems to be roughly a 3:1 cache hit-to-miss ratio. However, on OSX, ccache seems to be providing almost no benefit: we see something like a 1:15 cache hit-to-miss ratio -- at which point we might as well not be using ccache at all. I've been looking into this a bit with 3.0 (actually tip of tree) on OSX. Using ccache 3 [in its default mode of direct mode then fallback to preprocessor], 90%+ of the misses that I see in the log are failure to find the manifest file at all, and I'm seeing a similar very low hit rate overall. Right now I'm doing some tests around using the new CCACHE_SLOPPINESS=file_macro tweak, and initial results are promising... but that begs the question of why the results on OSX with 2.4 are so poor in general. The obvious guess is that there's *something* about our cross-build chain and environment that differs from the Linux-hosted versions just enough to be upsetting ccache. Any tips on what I should go looking for? Thanks! -- chris tate android framework engineer ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Stumbling blocks with ccache and embedded/encapsulated environments
On Wed, Dec 1, 2010 at 9:00 PM, Martin Pool m...@canonical.com wrote: On 11 November 2010 10:56, Christopher Tate ct...@google.com wrote: I don't want to rain on peoples' parade here, because ccache is a great product that has real benefits, but I do want to share some of our findings regarding the use of ccache in our very large product -- we were surprised by them, and you may be as well. These findings are specifically for *large products*. In our case, the total source code file size is on the order of 3 gigabytes (which includes not only C/C++ but also Java source files, a couple hundred thousand lines of makefiles, etc). It's the Android mobile phone OS, fwiw: it builds something like 1-2 gigabytes of .o files from C/C++ during a full build, and does a ton of Java compilation, resource compilation, Dalvik compilation, etc as well. I'd love to know whether you also tried distcc for it, and if so what happened or what went wrong. (Obviously it can only help for the C/C++ phases.) distcc can certainly help a great deal. For us, it's a bit problematic to use because more than half of our total build is non-C/C++ that depends on the C/C++ targets [e.g. Java-language modules that have partially native implementations], plus we have a highly heterogeneous set of build machines: both Mac hosts and Linux, not all the same distro of Linux, etc. The inclusion of Macs in particular makes distcc more of a pain to get up and running cleanly. The issue is around VM/file system buffer cache management. If you're using ccache, then you'll effectively be doubling the number of .o files that are paged into memory during the course of a build. I'm just trying to understand how this happens. Is it that when ccache misses it writes out an object file both to the cache directory and into the build directory, and both will be in the buffer cache? So it's not so much they're paged in, but they are dirtied in memory and will still be held there. Even on a ccache *hit* both copies of the .o file wind up occupying buffer cache space, because the ccached .o is read from disk [paging it in] in order to write the .o file to the build output directory. On a ccache miss the copy runs the other direction but you still wind up with both sets of pages in the buffer cache. It seems like turning on compression would reduce the effect. At the expense of the extra cpu time, sure. That might be a decent tradeoff; modern cpus are getting quite fast relative to I/O. Turning on hardlinking might eliminate it altogether, though that could have other bad effects. Right. We haven't tried pursuing this because for other reasons the marginal returns are still pretty low, and tinkering with the build system is fraught with peril. :) -- christopher tate android framework engineer ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Problem with using ccache during kernel compilation
If removing the .o files and recompiling results in pulling the .o files out of ccache, but reconfiguring and recompiling does *not*, that implies that the configuration step is literally producing some textually different source file contents each time. Does the kernel configuration include e.g. a generated string containing the timestamp of when the configuration was performed, or some such thing? That sort of thing can easily force a full recompilation (since it would mean that after each reconfiguration, even with the same settings and no other source changes, the text of each compilation module would indeed be different). -- chris On Tue, Jan 21, 2014 at 4:15 AM, Andrew Stubbs a...@codesourcery.com wrote: On 15/01/14 16:16, Piotr Kiszka wrote: I am trying to use ccache during kernel building.But there is always zero cache hits during second kernel compilation: I've observed this also. It's annoying! The problem seems to be something in the way the kernel config autogenerates the header files. I did find out what it was, but I've forgotten now. In fact, if you build the kernel, then delete all the .o files, and then run make again, you *do* get cache hits. make clean might be OK too, I'm not sure. Only if you start from completely clean, or reconfigure, then it doesn't work. Of course, this is the usual use case. I don't recall finding a workable solution. Sorry. Andrew P.s. A nice feature for ccache would be for it to report *why* a cached result wasn't found. This would only be meaningful in direct-mode, but still might be helpful. In preprocessor mode, *I* might find a list of hashes useful, so I could compare between runs, but this wouldn't be universally helpful, I suspect. ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
