0

Recently I wrote a (highly optimized) LALR(1) parser (that could handle ambiguous grammars) and supplied it a very ambiguous grammar. After that, I wrote a recursive descent parser for the same grammar, but with all the ambiguity taken out. I've read many times that LALR(1) parsers are very efficient, and recursive descent parsers are very inefficient, so I naturally expected the LALR parser to run much faster, even though it had an ambiguous grammar. When I compared the results of the two runs, I was shocked-- the recursive descent parser much faster than the LALR parser! Why was the LALR parser slower than the recursive descent parser? Was it because the LALR parser had an ambiguous grammar?

xilpex
  • 3,097
  • 2
  • 14
  • 45
  • 1
    Who knows? Maybe your parser is not as highly-optimized as you think it is. Maybe the algorithm you used to handle ambiguities isn't very fast. Maybe there's just a simple bug hiding somewhere. Show some details and maybe someone can provide a useful answer. – rici Apr 18 '20 at 20:39
  • LALR(1) grammars are by definition not ambiguous -- so if your parser could handle an ambiguous grammar, its not LALR(1). – Chris Dodd Apr 18 '20 at 21:07
  • Can you elaborate on how your parser works? LALR(1) parsers refer to a specific family of parsers that make strong assumptions about the grammar. If you've generalized this, great! That's really exciting, and the details of how you generalized this are what's going to matter. – templatetypedef May 29 '20 at 01:27

0 Answers0