mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Schwartzmeyer <>
Subject Re: Proposal for Mesos Build Improvements
Date Wed, 15 Feb 2017 21:30:44 GMT

I worked with Jeff on the initial proposal for pre-compiled headers and library refactor.
I think this thread should focus on the former, potentially implementing pre-compiled headers,
and have a separate conversation on Jeff's original second suggestion of using more libraries
inside Mesos.

With that in mind, I think we have some requirements for the pre-compiled header implementation.

* First and foremost, we need a benchmarked prototype that proves pre-compiled headers provide
a considerable speed-up. As the most complex headers are those of the header-only Stout library,
we should also benchmark improvements from making Stout non-header-only, and then prioritize;
but this will likely be a separate discussion.

* We must maintain ccache compatibility, as the majority of Mesos developers already use ccache.
It appears the most straightforward way to do this is to _not_ `#include common.h`, but to
`-include` it; this fits well with the next requirement.

* We must maintain correct includes; i.e. Mesos should be compilable without the pre-compiled
header. Because of multiple-include optimization, this should not affect the gains from the
use of pre-compiled headers. Again, this fits well with the next requirement.

* We should automatically generate the pre-compiled header, as this eliminates manual maintenance.
Combined with the above two points, this approach should actually negate the original code-churn
problem. By generating a common header to pre-compile, and using `-include`, we will not have
to modify existing source files. This would both give us ccache compatibility and ensure that
the correct includes would be maintained (and thus can be refactored independently of this

Did I miss any points, or can we move forward with prototyping this?


-- Andy

From: Benjamin Bannier <>
Sent: Wednesday, February 15, 2017 12:26 PM
To: dev
Subject: Re: Proposal for Mesos Build Improvements


> 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).

That’s an interesting angle for a number of reasons. It would allow local reasoning about
correct includes, and it also appears to help maintain support for ccache’d builds,

For that one could include project headers such as `mesos_common.h` via a command line switch
to the compiler invocation, without the need to make any changes to source files (possibly
an interesting way to create some benchmarking POC of this proposal).

Not changing source files for this would be valuable as it would keep build setup idiosyncrasies
out of the source. If we wouldn’t change files we’d keep the possibility to make PCH use
opt-in. Right now a ccache build of the Mesos source files and tests with warm ccache takes
less than 50s on my 8 core machine (a substantial fraction of this time is spent in serializing
(non-parallelizable) linking steps, and I’d bet there is also some ~10s overhead from Make
stat’ing files and changing directories in there).

Generating precompiled headers would throw in additional serializing step, and even if it
really only would take 20s to generate a header as guestimated by Jeff, we would already be
approaching a point of diminishing returns on platforms with ccache, even if we compiled every
source file in no time.

> Does anyone know whether the header guard in <b> _should_ make the repeated
> inclusion of <b> relatively cheap?

Not sure how much information gcc or clang would need to serialize from the PCH, but there
is of course some form of multi-include optimization in both gcc and clang, see e.g.,



View raw message