«

On Feb 17, 1:53*pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 02/18/11 03:05 AM, David Resnick wrote:
> All of the PCH systems I've used rely on the order of header inclusion
> being the same in each translation unit, so putting all the system
> headers in one file guarantees this. *The compiler will cache the result
> of parsing those headers and used the cached data whenever that sequence
> of include files is encountered.

Hmmm, but how does that deal with the fact that a header is often
"dynamic" in that
different patterns of macro definitions may result in a different
parsing?
As in the common:
#define NDEBUG
#include <assert.h>

vs
#include <assert.h>
>
> > Mostly moot for system headers I agree, as they are mostly on the
> > local filesystem, etc. *None of the regular code I use is on the
> > local filesystem (we use Clearcase, which uses a virtual file
> > system with the files residing elsewhere on a view server).
> > Certainly
> > for normal header files, it is a cost to include files you don't care
> > about, as the time to rebuild a large code base is significant and
> > unneeded depencencies make it worse...
>
> But the files will be cached on the local host.

I'm not sure how much caching is done in mvfs, but I'd guess that each
read of a file in clearcase at least needs some minimal check of the
server to see if the file has changed since last accessed.

But my bigger issue which basically only applies to non-standard
library files isn't fetching the files. It is the build
dependencies. In the worst case, if your paradigm is to include every
known header in every source file to avoid having to figure out which
really need to be included, anyone touching any header would trigger a
global rebuild. In my project, that would be some thousands of C++
files that take some hours to rebuild, irritating when it happens in
the middle of the day.

-David

Le 17/02/11 19:53, Ian Collins a écrit :
> On 02/18/11 03:05 AM, David Resnick wrote:
>> On Feb 16, 3:12 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>>> On 02/17/11 05:07 AM, David Resnick wrote:
>>
>>>> I'm not sure it is bad "style", but it can certainly cause performance
>>>> issues in a large scale build to access/read/parse all the unneeded
>>>> header files, particularly if they aren't on a local filesystem.
>>>
>>> The opposite may also be true; if your compiler supports pre-compiled
>>> headers, it can speed things up. Unless you have an awful lot of
>>> headers and not a lot of RAM, the OS will probably have cached them all
>>> on first read, so remote files doesn't usually have too big an impact.
>>
>> I can't see how including a header that includes all system headers
>> in every file could ever speed things up relative to the selective
>> inclusion in each file of exactly what is needed. Why would this be?
>> I'm a bit murky on pre-compiled headers, haven't dealt with them,
>> but do they work if they have anything that depends on the compile
>> time defines that riddle many system headers?
>
> All of the PCH systems I've used rely on the order of header inclusion
> being the same in each translation unit, so putting all the system
> headers in one file guarantees this. The compiler will cache the result
> of parsing those headers and used the cached data whenever that sequence
> of include files is encountered.
>
>> Mostly moot for system headers I agree, as they are mostly on the
>> local filesystem, etc. None of the regular code I use is on the
>> local filesystem (we use Clearcase, which uses a virtual file
>> system with the files residing elsewhere on a view server).
>> Certainly
>> for normal header files, it is a cost to include files you don't care
>> about, as the time to rebuild a large code base is significant and
>> unneeded depencencies make it worse...
>
> But the files will be cached on the local host.
>

Yes, and the cost of inclusion can be avoided with
#pragma once
or the old
#ifndef __STDHEADERS_H
#define __STDHEADERS_H
....
#endif

jacob navia <> writes:
> Le 17/02/11 19:53, Ian Collins a ecrit :
[...]
>> But the files will be cached on the local host.
>>
>
> Yes, and the cost of inclusion can be avoided with
> #pragma once

Which is of course non-standard, but it's widely implemented.
Implementing it correctly in the presence of, for example, symbolic
links that refer to the same file can be tricky.

> or the old
> #ifndef __STDHEADERS_H
> #define __STDHEADERS_H
> ...
> #endif

Which still incurs the cost of scanning the entire file (unless the
compiler specifically optimizes this case, as I understand gcc does).

Note that the identifier __STDHEADERS_H is reserved to the
implementation.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 02/18/11 08:07 AM, David Resnick wrote:
> On Feb 17, 1:53 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>> On 02/18/11 03:05 AM, David Resnick wrote:
>> All of the PCH systems I've used rely on the order of header inclusion
>> being the same in each translation unit, so putting all the system
>> headers in one file guarantees this. The compiler will cache the result
>> of parsing those headers and used the cached data whenever that sequence
>> of include files is encountered.
>
> Hmmm, but how does that deal with the fact that a header is often
> "dynamic" in that
> different patterns of macro definitions may result in a different
> parsing?
> As in the common:
> #define NDEBUG
> #include<assert.h>

I haven't done any test, but I'd expect it to be conservative and
consider the inclusion different.

--
Ian Collins