mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Coffler <Jeff.Coff...@microsoft.com.INVALID>
Subject RE: Proposal for Mesos Build Improvements
Date Wed, 15 Feb 2017 19:29:17 GMT
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.alexander@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.Coffler@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
>

Mime
View raw message