On Thu, Oct 15, 2020 at 11:05 AM Zachary Turner
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
