Re: Where does the time go?

[Diego Novillo <dnovillo@google.com>]

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.