Hi, 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 work). Did I miss any points, or can we move forward with prototyping this? Thanks, -- Andy ________________________________________ From: Benjamin Bannier <benjamin.bann...@mesosphere.io> Sent: Wednesday, February 15, 2017 12:26 PM To: dev Subject: Re: Proposal for Mesos Build Improvements Hi, > 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, https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fccache.samba.org%2Fmanual.html%23_precompiled_headers&data=02%7C01%7Candschwa%40microsoft.com%7C03f9ebaea1e3491c81e908d455e0e8ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636227871844766180&sdata=iWmHFa2Zpg%2B9nP7p8rtuJ20dS7k7bVXommvbqfg%2FLuA%3D&reserved=0 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., https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fcppinternals%2FGuard-Macros.html&data=02%7C01%7Candschwa%40microsoft.com%7C03f9ebaea1e3491c81e908d455e0e8ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636227871844766180&sdata=6eD5zC%2F62TgfS9q9EdCVh%2BLkQ8FqBiLc4VNc%2BR1Zn4k%3D&reserved=0 Cheers, Benjamin
