This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: some profiling numbers
Zack Weinberg wrote:
This is very interesting stuff, thanks for doing it. A few comments:
- If you haven't already, please make sure all the internal
consistency checks are disabled, by specifying --disable-checking to
configure.
I haven't checked this, so I will. possibly it is a major source of
distortion.
- You call out the preprocessor (cpp*.c) as a source of additional
code between 2.95 and 3.0, but this is not entirely fair, because
all the same work was being done in 2.95 but in a separate
executable. I would like to see higher level information about time
spent in *all* the programs run in the course of a kernel build -- I
believe oprofile is ideally suited to collecting such information.
(It looks like this information is in the first few charts at the
top of the report, but not in others.)
sorry for being unclear; in all profiles I am summing the times spent in
cpp and cc1, both. what I meant was that some preprocessor-related
symbols did increase. I do not know if this is because they didn't exist
in the old preprocessor (and got added) or because they are implemented
in a more slow way in the new preprocessor. haven't looked closely.
- bison.simple being at the top of the 2.95->3.0 code-bloat chart is
kind of suspicious; could you please make sure that all your test
compilers generated c-parse.c with the exact same version of bison?
I believe 1.35 and later work with 2.95 and later.
I will check, but I did all the builds from a single batch script on one
machine. does gcc build its own bison, perhaps?
- Could we get that same code-bloat chart with information about 3.1,
3.2, 3.3 and mainline? I suspect the problem spots may be rather
different by now.
- And would it be possible to go into a bit more detail about the
problem routines in each of these files?
it can produce many more profiles, and annotated sources, yes. no call
graphs in the current release, but that will be forthcoming. part of the
idea with producing these reports was to show the general technique and
encourage those people interested in performance tuning to give the
profiler a try for themselves. there's an endless list of experiments
and results one might want to run, and I can only run so many of them.
-graydon