3 ms·

Most modern C compilers are aware of include guards: if they notice that the _entire_ file is enclosed in include guards, they won't read it a second time.

by pdw 6y ago

pjmlp 6y ago
That breaks undefs before includes.
- pdw 6y ago
  Well yeah. If you make normal, idiomatic use of include guards, compilers will be able to apply this optimization. If you do weird stuff, they'll be forced to re-read the file. https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.htm...
guenthert 6y ago
I haven't opened up my C compiler to verify this, but even for ancient compilers that would be a non-issue, as they see only what the preprocessor hands them. Re-reading (i.e. parsing by the preprocessor) an include file isn't so bad either, as it is already cached. I find this focus on compilation speed curious. At my last workplace a full built took a good share of the day (!) and was typically done overnight. Building during the daytime was discouraged, as it happened on our workstations, slowing down everything else. We found ways to cope, chiefly learning which subsets are autarkic, i.e. finding the least general Makefile which when invoked would catch your recent changes and wouldn't traverse too much of the tree. Not ideal, but workable.
- algo_trader 6y ago
  > full built took a good share of the day Yikes Was this with/out some sort of cluster support? Which language? Is this due to legacy practices, or is it simply a difficult build? I am asking because i am involved with a parallel build project. and often there is plenty low hanging fruits
  - guenthert 6y ago
    > Yikes Was this with/out some sort of cluster support? Each developer built on their own workstation. We meant to look into built-cluster, but we never got around to it. > Which language? C++ mostly old style, some C++11, quite a bit of template programming (but I haven't seen anything too fancy). > Is this due to legacy practices, or is it simply a difficult build? It sure was an old code base, not sure what you mean by legacy practices (but that might make it a yes ;-} Not sure either, what would make it difficult, but there were C++ templates and it was fairly large (sum of resulting object files in the order of a few hundred MiB).

Most modern C compilers are aware of include guards: if they notice that the _entire_ file is enclosed in include guards, they won't read it a second time.

by pdw 6y ago

Most modern C compilers are aware of include guards: if they notice that the _entire_ file is enclosed in include guards, they won't read it a second time.

pjmlp 6y ago

That breaks undefs before includes.

pdw 6y ago
Well yeah. If you make normal, idiomatic use of include guards, compilers will be able to apply this optimization. If you do weird stuff, they'll be forced to re-read the file. https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.htm...

guenthert 6y ago

I haven't opened up my C compiler to verify this, but even for ancient compilers that would be a non-issue, as they see only what the preprocessor hands them. Re-reading (i.e. parsing by the preprocessor) an include file isn't so bad either, as it is already cached. I find this focus on compilation speed curious. At my last workplace a full built took a good share of the day (!) and was typically done overnight. Building during the daytime was discouraged, as it happened on our workstations, slowing down everything else. We found ways to cope, chiefly learning which subsets are autarkic, i.e. finding the least general Makefile which when invoked would catch your recent changes and wouldn't traverse too much of the tree. Not ideal, but workable.

algo_trader 6y ago
> full built took a good share of the day Yikes Was this with/out some sort of cluster support? Which language? Is this due to legacy practices, or is it simply a difficult build? I am asking because i am involved with a parallel build project. and often there is plenty low hanging fruits
- guenthert 6y ago
  > Yikes Was this with/out some sort of cluster support? Each developer built on their own workstation. We meant to look into built-cluster, but we never got around to it. > Which language? C++ mostly old style, some C++11, quite a bit of template programming (but I haven't seen anything too fancy). > Is this due to legacy practices, or is it simply a difficult build? It sure was an old code base, not sure what you mean by legacy practices (but that might make it a yes ;-} Not sure either, what would make it difficult, but there were C++ templates and it was fairly large (sum of resulting object files in the order of a few hundred MiB).