I agree with the first part (PCHs will introduce some additional dependencies 
for some object files).

I do not agree with the second point (PCHs become bloated over time, thus 
reducing time savings).

The key point with PCH is that mesos_common.h is only read ONCE. Even if large 
and bloated, since it's only read once, the time savings is not diminished at 
all.

/Jeff

-----Original Message-----
From: Alex Clemmer [mailto:clemmer.alexan...@gmail.com] 
Sent: Wednesday, February 15, 2017 11:24 AM
To: dev <dev@mesos.apache.org>
Subject: Re: Proposal for Mesos Build Improvements

Yes, that is right, PCHs would probably introduce some additional dependencies 
for some object files, and if those PCHs become bloated over time, then you can 
expect this to be expressed as diminishing time savings.

This does imply that maintaining PCHs will require at least some work.


__
Transcribed by my voice-enabled refrigerator, please pardon chilly messages.

On Wed, 15 Feb 2017, Neil Conway wrote:

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

Reply via email to