This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Optimization Inquiry
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: "Joseph D. Wagner" <theman at josephdwagner dot info>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 01 Oct 2003 17:57:28 -0700
- Subject: Re: Optimization Inquiry
- References: <200310011923.04728.theman@josephdwagner.info>
"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