mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Conway <>
Subject Re: Proposal for Mesos Build Improvements
Date Wed, 15 Feb 2017 19:34:55 GMT
Hi Jeff,

Gotcha -- I just wanted to understand the tradeoffs here.

I'd definitely prefer an approach in which we include "<xyz>" in both
"mesos_common.hpp" and each individual file that logically depends on
"<xyz>". This makes clear the dependencies between modules and also
makes it easy to disable building with PCH (see also the
recommendations in [1]). If the only reason avoid this is the cost of
the repeated include, it would be important to see benchmarks that
justify this.

BTW, I think it's important that we script/automate this as far as
possible, e.g., using a script to decide which headers are included
often enough to justify being included in the PCH. This should avoid
the PCH getting out of date, as well as innumerable arguments down the
road about whether header X warrants being added to the PCH :)

Overall, sounds cool to me! Faster builds would be fantastic.



On Wed, Feb 15, 2017 at 11:26 AM, Jeff Coffler
<> wrote:
> 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
> /Jeff
> -----Original Message-----
> From: Neil Conway []
> Sent: Wednesday, February 15, 2017 11:13 AM
> To: dev <>
> Subject: Re: Proposal for Mesos Build Improvements
> On Tue, Feb 14, 2017 at 11:28 AM, Jeff Coffler <>
>> 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
> 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

View raw message