Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
From: Jeff Coffler <Jeff.Coffler@microsoft.com.INVALID>
To: "dev@mesos.apache.org" <dev@mesos.apache.org>
Subject: RE: Proposal for Mesos Build Improvements
Thread-Topic: Proposal for Mesos Build Improvements
Thread-Index: AdKG+AOAdK9amvQjS3yHvUXWC4IlxgAx3BkAAABkuwAAAB4/YA==
Date: Wed, 15 Feb 2017 19:29:17 +0000
Message-ID: <MWHPR03MB3056BA4B6A38630FD5D20D16975B0@MWHPR03MB3056.namprd03.prod.outlook.com>
References: <MWHPR03MB305696B28012360BC221DB0E97580@MWHPR03MB3056.namprd03.prod.outlook.com>
 <CAOW5sYZU1Cct3mhwuDpBsBNEfUk49CMaMegoYQxVMZP2x2TS5g@mail.gmail.com>
 <alpine.OSX.2.20.1702151120230.37348@fabienne-2.local>
In-Reply-To: <alpine.OSX.2.20.1702151120230.37348@fabienne-2.local>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 19:29:17.7307
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB3054
archived-at: Wed, 15 Feb 2017 19:29:44 -0000

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

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

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

/Jeff

-----Original Message-----
From: Alex Clemmer [mailto:clemmer.alexander@gmail.com]=20
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 dependenc=
ies 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=20
> <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 hea=
der is included in fewer than 50% of the source files, then it can be separ=
ately 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 sour=
ce files, if it's very large, we still may decide to throw it in the precom=
piled 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=20
> included in the precompiled header, the symbols in Y will now be=20
> visible when X is compiled. It would also mean that X would need to be=20
> recompiled when Y changes.
>
> Related: the current policy is that headers and implementation files=20
> should try to include all of their dependencies, without relying on=20
> transitive includes. For example, if foo.cpp includes bar.hpp, which=20
> includes <vector>, but foo.cpp also uses <vector>, both foo.cpp and=20
> bar.hpp should "#include <vector>". Adopting precompiled headers would=20
> 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=20
> "mesos_common.h>
>
> #include <b>
> #include <d>
>
> That way, the fact that "xyz.cpp" logically depends on <b> (but not=20
> <a> or <c>) is not obscured (in other words, Mesos should continue to=20
> compile if 'mesos_common.h' is replaced with an empty file). Does=20
> anyone know whether the header guard in <b> _should_ make the repeated=20
> inclusion of <b> relatively cheap?
>
> Neil
>