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):
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.
