This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Faster compilation speed
- From: Nix <nix at esperi dot demon dot co dot uk>
- To: Noel Yap <yap_noel at yahoo dot com>
- Cc: Neil Booth <neil at daikokuya dot co dot uk>, gcc at gcc dot gnu dot org
- Date: 11 Aug 2002 01:49:00 +0100
- Subject: Re: Faster compilation speed
- References: <20020810231247.83730.qmail@web21407.mail.yahoo.com>
[Cc: list trimmed]
On Sat, 10 Aug 2002, Noel Yap spake:
> I would agree if you're talking about complete builds
> spanning only a few C/C++ files. OTOH, when builds
> span many hundreds of these files, build-time (not
> just compile-time) starts getting bogged down on
> (mostly) reopening and repreprocessing the same files
> over and over.
>
> Within our system, builds on Windows are magnitudes
> faster since we're able to take advantage of
> precompiled headers.
Are you sure that this isn't because GCC is having to parse the headers
over and over again, while the precompiled system can avoid that
overhead?
Especially for C++ header files (which tend to be large, complex,
interdependent, and include a lot of code), the parsing and compilation
time *vastly* dominates the preprocessing time.
Example, with GCC-3.1, with a `hello world' iostreams-using program...
The code:
#include <iostream>
int main (void)
{
std::cout << "Hello world";
return 0;
}
Time spent preprocessing (distorted by the slowness of cpp's output
routines):
nix@loki 62 /tmp% time c++ -E -ftime-report hello.C >/dev/null
real 0m1.424s
user 0m0.710s
sys 0m0.100s
Time spent preprocessing and parsing (roughly; cpp's output routines are
still slow; on the trunk much less time will be spent preprocessing
because the integrated preprocessor doesn't have to do any output at all
there, instead feeding a token stream to the rest of the compiler):
nix@loki 60 /tmp% c++ -ftime-report -fsyntax-only hello.C
Execution times (seconds)
garbage collection : 1.16 (12%) usr 0.08 ( 6%) sys 2.19 (13%) wall
preprocessing : 1.04 (11%) usr 0.29 (20%) sys 2.10 (12%) wall
lexical analysis : 0.99 (10%) usr 0.28 (20%) sys 1.87 (11%) wall
parser : 6.12 (65%) usr 0.75 (53%) sys 10.85 (63%) wall
varconst : 0.08 ( 1%) usr 0.00 ( 0%) sys 0.10 ( 1%) wall
TOTAL : 9.44 1.42 17.21
(oddly, preprocessing took *longer* than it did using -E, which I'd not
expected; but, still parsing vastly dominates preprocessing, and this isn't
going near e.g. the STL headers)
Complete run, with optimization:
nix@loki 66 /tmp% c++ -O2 -ftime-report -o hello hello.C
Execution times (seconds)
garbage collection : 1.10 (11%) usr 0.11 ( 9%) sys 1.74 (11%) wall
cfg cleanup : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
life analysis : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
preprocessing : 1.12 (11%) usr 0.22 (18%) sys 2.04 (13%) wall
lexical analysis : 0.98 (10%) usr 0.22 (18%) sys 1.93 (12%) wall
parser : 6.46 (65%) usr 0.63 (53%) sys 9.98 (62%) wall
expand : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
varconst : 0.08 ( 1%) usr 0.00 ( 0%) sys 0.12 ( 1%) wall
CSE : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
CSE 2 : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
regmove : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
global alloc : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
flow 2 : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
rename registers : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
scheduling 2 : 0.00 ( 0%) usr 0.01 ( 1%) sys 0.02 ( 0%) wall
final : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
TOTAL : 9.96 1.20 16.16
Now obviously with a less toy example the time consumed optimizing would
rise; but that doesn't affect my point, that the lion's share of time
spent in C++ header files is parsing time, and that speeding up the
preprocessor will have limited effect now (thanks to Zack and Neil
speeding it up so much already :) ).
--
`There's something satisfying about killing JWZ over and over again.'
-- 1i, personal communication