Hacker News Reader

Comment by basman | Hacker News Reader

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?

View on HN

Indeed. 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.

No, 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.

sure, 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.

Yeah, 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.

Reply on news.ycombinator.com