This is the mail archive of the gcc@gcc.gnu.org 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 3.3 compile speed regression - AN ANSWER



Per Abrahamsen wrote:
> 
> Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> 
> > Has anyone looked at how much the binutils contribute to the end to
> > end performance question?  gas is involved in every compile and ld is
> > involved in every program link.  I just don't recall it every being
> > mentioned.
> 
> Speeding up ld would help my edit/compile/run cycle far more than
> speeding up gcc.
> 
> Probably because gcc typically only have to compile one file after an
> edit, while ld has to link 219 files.
> 
> Of course, for the rare cases where I have to build from scratch, gcc
> is dominating.

This makes sense.

When I posted that I was thinking of the cases like you mention. 
Compiling
one files, updating a library, and relinking multiple applications.  

Another case I was thinking of is compiling the powerpc simulator
in gdb with the option to inline all code.  The last time I watched,
the generated assembly file was 40 Mbytes and it was noticeable.  
Admittedly, this is the exception.

My point wasn't to divert the focus from gcc but to note that invoking
gcc involves a lot of subprograms and each contributes something to
the overall time.  Alan Modra pointed out that ld has a case where
it can be the culprit.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


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