Re: Why are LR parsers faster than using if conditions

Carl Cerecke said:


> But, if we are talking about speed, I suspect a hard-coded LR parser
> will leave even a well written recursive descent parser in its dust.


I recall somebody said that typical compilers spend most time
elsewhere than in the parser, e.g., the actions. So if that is the
case, the question of parsing method is pretty academic. The best
approach is probably to write your parser using a parser generator
that is makes the writing most easy (as human CPU time is very
expensive!), and then run it through a profiler to see if the parsing
takes up a significant amount of time.


There have been similar discussions in the Flex mailing list as to
whether certain features slow down the lexing. For example, instead of
using the built in location tracking mechanism, some insisted that one
should write ones own location tracking by tweaking the Flex grammar
rules. When I finally tried both variations out, it turned out that
the lexing time did not depend significantly at all. One thing that
did matter though, was whether the lexer rules matches long input
segment, in which case the lexer would sort of choke and become very
slow. This is clearly some kind of bug, say a buffer problem. But
until it has been fixed, one has in Flex to break up the lexer rules
so that the typical input matches do not become too large.


    Hans Aberg
[The numbers I've seen say that the lexer is usually the slowest part
of a compiler. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.