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: Optimization Inquiry


"Joseph D. Wagner" <theman@josephdwagner.info> writes:

> In analyzing GCC performance, I added some code to the *.c files in the gcc 
> directory in order to track which portions of code were being most 
> frequently executed.  The culprits, and hence files that should be most 
> targeted for optimization, are:
>
>  1. cpplex.c
>     (by a landslide; 9x more than any file)
>  2. cppmacro.c
>  3. cpplib.c
...

> NOTE: All references are to gcc version 3.3.1.  I want to be able to use and 
> test on a stable version of gcc to know that whatever problems may be 
> encountered are a result of the optimizations.

We really, really need you to do this kind of work against CVS HEAD.
I realize this exposes you to more "churn", but between 3.3.1 and HEAD
a lot of changes have been made, such that your numbers may not be
accurate anymore - and we're not taking performance patches for 3.3.2.

In particular, cpplex.c was drastically reworked in HEAD, and the loop
you identified as a major bottleneck has been changed quite a bit.  It
may still be a bottleneck.  (In the future, please mention the name of
the function containing any bottleneck you identify.  Line numbers
change often; function names less often.)

It's interesting that you identify the block-comment skipper as a
major bottleneck.  This may say more about your input code than
anything else.  When I've done similar profiles, lex_identifier has
been a bigger issue than skip_block_comment.

> NOTE: My analysis is not complete.  I was only able to analyze files a*.c 
> through c*.c.  In other words, there may be some file worse than those I 
> mentioned hiding out in d*.c through x*.c, but it's too early to tell.
...

There almost certainly is.  Whole-program profiling has generally put
cpp*.c as taking 5-10% of total runtime on typical code.  You can
sanity-check your numbers by using -ftime-report to get an idea of the
time consumed by each pass.

It sounds like you are doing arc profiling -- you may want to look at
the gcov utility, which does similar instrumentation in an automated
fashion.

zw


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