I think this is a nice start, but we need to go deeper: how much of the recompilation is due to which target dependencies changing? E.g., if we didn’t have the monolith :core target, what would have needed recompilation vs what is recompiled today? Cache only works if the dependencies are detangled, if independent parts are intermingled for historical reasons then there’ll be a lot of rebuilding. Also, how does the proposed work on making shared libraries support proper affect this? (These may be intermingled as tot get the best shared library, one would need better deps, but if statistically all linked together then cache hits will be lower and link time higher).
But I think that goes to the above question: who is the user that this affecting? E.g., using the git development model, I’d be on a branch getting my work done up until sending for review and would hit this only if I manually pull (so I choose the frequency). At the point where I do that (and I think Mihai’s numbers may be with a RBE as I can’t built TF under an hour on my machine without a populated cache), I context switch and work on something else done. So updating affects a user that is pulling frequently for some reason, but not quickly enough to get enough cache reuse?