Ni Neil, What you're saying is essentially correct. If mesos_common.h includes a bunch of, well, "common" stuff, and everybody includes mesos_common.h, then those files will, by definition, have a least some number of items that they didn't need.
Since PCH works on both Windows and Linux, I don't think this is a "bad thing". It's a trade-off. Is a (what I believe to be) very significant speed-up in compile speed "worth it"? (Obviously, since I submitted the proposal, I think so. But this is a very valid point). Yes, header guards will help, but header guards are not free. I would rather not include a really large set of headers (say, windows.h, or stout) multiple times, expecting header guards to make them fast. I'd rather just include them once, in mesos_common.h. And this would also yield the greatest performance enhancement as well. I'm working on getting some hard numbers for a subset of Mesos. Once we have some hard comparisons with compiler performance (with and without PCH), we can address this much more practically. /Jeff -----Original Message----- From: Neil Conway [mailto:neil.con...@gmail.com] Sent: Wednesday, February 15, 2017 11:13 AM To: dev <dev@mesos.apache.org> Subject: Re: Proposal for Mesos Build Improvements On Tue, Feb 14, 2017 at 11:28 AM, Jeff Coffler <jeff.coff...@microsoft.com.invalid> wrote: > For efficiency purposes, if a header file is included by 50% or more of the > source files, it should be included in the precompiled header. If a header is > included in fewer than 50% of the source files, then it can be separately > included (and thus would not benefit from precompiled headers). Note that > this is a guideline; even if a header is used by less than 50% of source > files, if it's very large, we still may decide to throw it in the precompiled > header. It seems like this would have the effect of creating many false dependencies: if file X doesn't currently include header Y but Y is included in the precompiled header, the symbols in Y will now be visible when X is compiled. It would also mean that X would need to be recompiled when Y changes. Related: the current policy is that headers and implementation files should try to include all of their dependencies, without relying on transitive includes. For example, if foo.cpp includes bar.hpp, which includes <vector>, but foo.cpp also uses <vector>, both foo.cpp and bar.hpp should "#include <vector>". Adopting precompiled headers would mean making an exception to this policy, right? I wonder if we should instead use headers like: <- mesos_common.h -> #include <a> #include <b> #include <c> <- xyz.cpp, which needs headers "b" and "d" -> #include "mesos_common.h> #include <b> #include <d> That way, the fact that "xyz.cpp" logically depends on <b> (but not <a> or <c>) is not obscured (in other words, Mesos should continue to compile if 'mesos_common.h' is replaced with an empty file). Does anyone know whether the header guard in <b> _should_ make the repeated inclusion of <b> relatively cheap? Neil
