some profiling numbers

[Zack Weinberg]

graydon hoare <graydon@redhat.com> writes:

>>- 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.

Now that I think about it, I remember the preprocessor being somewhat
slower in 3.0, but a lot of performance work has gone into it since.
This is a reason why I would like to see code-bloat charts comparing
all the members of the 3.x series, rather than just 2.95 and 3.0.  The
shape of the world is rather different now.

>>- 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?

It does not build its own bison, but it does ship generated parsers
with release tarballs, and I would not be surprised if the bison
version used had changed.  Deleting gcc/c-parse.c and
gcc/cp/parse.[ch] before each build should suffice to eliminate this
source of variation, if you only have one version of bison installed.

> 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.

I'm interested in trying some experiments myself, but I have never
managed to get oprofile to work, and you already have the setup.

zw