This is the mail archive of the
mailing list for the GCC project.
Re: Some (small) c++ compilation profiling data (oprofile)
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Zack Weinberg <zack at codesourcery dot com>, John Levon <levon at movementarian dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 21 May 2002 01:16:29 -0700
- Subject: Re: Some (small) c++ compilation profiling data (oprofile)
- References: <20020521043955.GA2991@codesourcery.com>
--On Monday, May 20, 2002 09:39:55 PM -0700 Zack Weinberg
> On Sun, May 19, 2002 at 01:26:13AM +0100, John Levon wrote:
>> Time spent
>> VMA Samples %age total symbol
> Heh. These
>> 081a1f90 88239 1.04199 output_format
>> 084107f4 92606 1.09356 dyn_string_append_cstr_len
>> 0808bbc0 145033 1.71266 cp_thing
>> 081a1dc0 148982 1.75929 wrap_text
> are only used to generate diagnostic messages. Did it spew a ton of
> errors before giving up?
> Unfortunately, that means this isn't much of a comparison of the
> parsers, since we wind up doing different work.
>> 0823b090 91493 1.08042 ht_lookup
>> 0813a030 101159 1.19456 walk_tree
>> 0815f720 110315 1.30268 cp_parser_lookup_name
>> 080788a0 142408 1.68166 grokdeclarator
>> 0835ce50 158204 1.86819 ggc_alloc
>> 0835d310 399979 4.72325 ggc_set_mark
>> 082388b0 403951 4.77015 ggc_mark_trees
> The absence of any other cp_parser_* functions in this is a hopeful
> sign, though.
Note that the new parser has not been tuned for speed *at all*. Heck,
I didn't even do the usual operator precedence stuff; we do the full
recursion for expressions in the naive way you would if you typed in
the C++ grammar directly.
I've got a few tricks up my sleeve for the new parser -- but
correctness first. That's hard enough, for now...
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com