4 ms·
The rule against nested includes seems dated — he doesn't like include guards in header files because "[t]he result is often thousands of needless lines of code
by basman 16y ago
The rule against nested includes seems dated — he doesn't like include guards in header files because "[t]he result is often thousands of needless lines of code passing through the lexical analyzer, which is (in good compilers) the most expensive phase." Surely not any more?
- cdavid 16y agoIndeed. I have read that parsing is the slowest part of compilation several times, but I guess this is very dated. For example, compiling numpy (a python package with ~ 100 kLOC of C code): - CFLAGS="-O0" -> ~ 20 sec - CFLAGS="-O1" -> ~ 35 sec - CFLAGS="-O3" -> ~ 60 sec Since the amount of parsed code for those modes is approximately the same (for numpy it is exactly the same, but one could imagine differences in glibc headers, etc...), this shows that parsing is not the bottleneck anymore if you build non-debug builds.
- mfukar 16y agoNo, that shows that the optimizer work takes a non-trivial amount of time. Optimizations (how often?) happen after parsing, type-checking and constructing the intermediate representation.
- cdavid 16y agosure, that's exactly the point I am trying to make: if it takes 75 % time more to compile @ O1 than O0, it means that parsing takes at most ~ 60 % of compilation time for quite conservative optimization. I think it is quite common to compile above the lowest level of optimization. To have an accurate estimation, one could look at clang, and only run the tokenizer.
- gte910h 16y agoYeah, the parsing argument is bunk anyhow. The pre-processor parsing is trivial and fast. Its the actual language which is the bulk of the time.