On Thu, Oct 15, 2020 at 11:05 AM Zachary Turner <divisorthe...@gmail.com> wrote:
> Hi there, > > Not sure if this is the right place to ask this question. I'm trying out > sccache on a non-Mozilla project and am running into 2 big issues on > Windows. > This isn't a good place to discuss this question. I think the best place is on a Github issue: could you file one at https://github.com/mozilla/sccache? > First issue is lack of precompiled header support. Without PCH a build > with 0 cache hits takes upwards of 20 minutes, whereas with PCH it takes > about 3 minutes. Is there anything I can do about this? I tried removing > the /Fp switch from the command line but leaving on /Yu and it seemed to > start getting cache hits, but I'm not sure if there's any negative side > effects associated with this. > > Second issue is that I'm not actually sure caching is working correctly. > To be sure PCH wasn't involved I actually disabled PCH entirely for my > build. Here are the times for one of our smaller internal targets (208 cpp > files): > > Sccache disabled (0 hits, 0 misses): 4.424 seconds > > [cache on same physical ssd as build directory] > Empty cache (208 misses, 0 hits): 12.193 seconds > Full cache (0 misses, 208 hits): 9.12 seconds > > [cache on different physical disk (ssd) as build directory (ssd)] > Empty cache (208 misses, 0 hits): 12.908 seconds > Full cache (0 misses, 208 hits): 9.017 seconds > > So the cache is making a difference, but it's still slower than not having > a cache in the first place. > > One thing that I don't understand is that even in the case where I get > 100% cache hit rate, a bunch of cl.exe processes spin up and appear to be > doing work. > This I can shed light on. The way that sccache works is that it preprocesses your source before hashing it as an input to the cache. So my guess is that you're witnessing the preprocessing costs. This is a known trade-off in the sccache design. ccache offers "immediate" mode to avoid this, where file timestamps are checked to avoid having to re-preprocess inputs to determine cache hits. That trades off correctness for efficiency. Does anyone have any suggestions on how I might diagnose this, or is this > expected? > We'd need some more logging and diagnostics to understand the performance you're seeing. (And I can't say anything about PCH support, sorry.) Let's take the follow-up to a Github issue. Thanks! Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
