This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc compile-time performance


> It's also interesting to note how the compiler tree keeps taking
> longer to compile.

Interesting isn't my word of choice. The key point here though is that this is 
to be expected, especially as new front-ends and features are added. What is 
not as expected is a constant increase in compile-time on the same code.
> I can't imagine recent gcc's compiling in under a minute on that kind
> of hardware.

Gracious no! My results so far (same 733MHZ i686-pc-linux-gnu, using gcc as the bootstrap compiler)

just make with C language enabled:
gcc	0m37.650s
gcc 2.8.1		0m45.840s
gcc 2.90.29	1m27.310s
gcc 2.91.66	1m39.370s
gcc 2.95.3	1m56.250s
gcc 3.0.4		3m43.970s
gcc 3.1		4m5.530s

this isn't half bad. But look at make with all languages enabled (not really 
an apples to apples comparison, but that's what a user would see):

make with all default languages enabled:
gcc	0m54.380s	(c,c++,objc)
gcc 2.8.1		1m5.980s		(c,c++,objc)
gcc 2.90.29	2m44.120s	(c,c++,objc,f77)
gcc 2.91.66	2m54.430s	(c,c++,obc,f77)
gcc 2.95.3	4m30.960s	(c,c++,objc,f77,libstdc++,java,chill)
gcc 3.0.4		20m32.940s	(c,c++,objc,f77,libstdc++,java,fixinc)
gcc 3.1		34m35.440s	(c,c++,objc,f77,libstdc++,java,fixinc)

One other note: if I disable java (which is a bit more difficult than it needs 
to be, why not a --disable flag?), I get:
gcc 3.1		11m46.390s	(c,c++,objc,f77,libstdc++,fixinc)

Food for thought I guess...

> However, I do feel that generated code quality is an order of
> magnitude more important than the time required to produce it, which
> is in turn an order of magnitude more important than the time it takes
> to build the compiler itself.

Agreed. However, my point is that in my experience, gcc tends to generate good 
quality code, it is primarily the time taken to generate that code that can 
become a problem. I certainly understand the need and interest in adding new 
optimizers (and quite appreciate it) but I think when one builds something at 
-O2, one expects that only both safe and obvious optimizations are applied. 
Thus I think significant increases in compile-time at -O2 are an issue (if 
I'm making a false assumption about -O2, please correct me). We do have -O3 
too after all ;-)


P.S. On a side note, how do I disable running fixincludes entirely? I don't 
object to running them, but they just add another variable to collecting 
build statistics, and my process is unscientific enough as it is.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]