Interesting. Thanks for gathering this. I did a similar study internally on our C++ codebase. The results are fairly different. In our case, the front end takes a LARGE chunk of the compile time. The numbers below are taken from a full build of one of our applications, consisting of ~4,500 C++ files. These are the aggregated times for an -O0 build (only the first 10 main contributors shown):
TOTAL : 11583.19 cpu sec, 3705.69 sys sec, 16012.79 wall sec, 841456705 kB parser : 6057.47 cpu sec, 1717.66 sys sec, 7955.42 wall sec, 580829675 kB name lookup : 1688.17 cpu sec, 1011.80 sys sec, 2750.34 wall sec, 93255238 kB preprocessing : 796.18 cpu sec, 575.73 sys sec, 1777.63 wall sec, 14743549 kB tree |^ dominator : 1067.33 cpu sec, 197.20 sys sec, 1290.34 wall sec, 101280196 kB tree gimplify : 973.18 cpu sec, 175.87 sys sec, 1172.88 wall sec, 96888948 kB garbage collection : 471.20 cpu sec, 22.20 sys sec, 499.94 wall sec, 0 kB expand : 339.34 cpu sec, 39.46 sys sec, 386.19 wall sec, 17818728 kB varconst : 336.20 cpu sec, 45.11 sys sec, 383.70 wall sec, 10064103 kB final : 111.79 cpu sec, 13.64 sys sec, 131.18 wall sec, 801421 kB The front end (parser + name lookup + preprocessing) is taking 78% of the wall clock time. What was surprising is that this ratio is fairly consistently maintained across three kinds of builds: optimized (-O2), not optimized (-O0) and debug (-g -O0). In an optimized build, the difference was that the front end reduced its contribution from 78% to 70%. In all cases, the gimplifier took about 6% of the total compile time. For debug builds, the difference was a 6% of time taken by symout. We are currently looking at ways of speeding up builds internally. Based on this, we are mostly looking at ways of making the front end faster. This profile is fairly consistent across much of our code base. Diego.
