Re: parser performance, was Popularity of compiler tools, was LRgen

Ian Lance Taylor <ian@[EMAIL PROTECTED]
> writes:

> > [My understanding is that GCC switched to a hand-written parser
> > because of the difficulty of parsing the awful C++ grammar with
> > anything other than hand-written hacks.  The new parser may be a
> > little faster but that wasn't a big issue, since parse time is never a
> > bottleneck in a compiler. -John]
>
> I want to disagree with our esteemed moderator a little bit.  Parsing
> time is not a bottleneck when optimizing.  But the speed of the
> compiler matters more when not optimizing, and in that case the parser
> can indeed be a bottleneck.  When compiling C++ with gcc with a lot of
> header files, the parsing time can be up to 50% of the total
> compilation time when not optimizing.
>
> Ian
> [Are you including tokenizing in the 50%?  Lexers often do take a lot
> of time, since they have to do something to each character.  But once
> the lexer has shrunk the input from a stream of characters to a stream
> of tokens, the parser rarely takes an appreciable amount of time.
> Opinions vary about the relative performance of DFA lexers vs ad-hoc
> hand written ones, which I think means that the implementation is more
> im****tant than the technique.  -John]

The 50% does include tokenizing, but still parsing is more than half
of that.  C++ files can easily include hundreds of thousands of lines
of header files, and gcc parses all of them even though very few of
them will be used by anything after the parsing stage.

I should add that I agree with your main point that there probably
isn't much speed difference between a hand-written parser and a
generated parser.  I just want to make the point that parsing speed
actually is relevant in practice.

gcc now uses a hand-written parser for C too, by the way.

Ian