Related articles |
---|
Recursive Descent Parsers and YACC melling@psuvax1.cs.psu.edu (1990-11-15) |
Re: Recursive Descent Parsers and YACC pardo@cs.washington.edu (1990-11-16) |
Re: Recursive Descent Parsers and YACC grimlok@hubcap.clemson.edu (1990-11-16) |
Re: Recursive Descent Parsers and YACC Bruce.Hoult@actrix.co.nz (1990-11-18) |
Re: Recursive Descent Parsers and YACC dave@labtam.labtam.oz.au (1990-11-20) |
Re: Recursive Descent Parsers and YACC hankd@ecn.purdue.edu (1990-11-17) |
Re: Recursive Descent Parsers and YACC henry@zoo.toronto.edu (1990-11-17) |
Re: Recursive Descent Parsers and YACC mailrus!sharkey!hela!iti.org!dhw@uunet.UU.NETid AA (1990-11-20) |
Recursive Descent Parsers and YACC grosch@gmdka.uucp (Josef Grosch) (1990-11-22) |
[5 later articles] |
Newsgroups: | comp.compilers |
From: | grimlok@hubcap.clemson.edu (Mike Percy) |
Keywords: | parse, yacc, design, question |
Organization: | Clemson University, Clemson, SC |
References: | <F7p?bk63@cs.psu.edu> |
Date: | 16 Nov 90 21:03:54 GMT |
melling@psuvax1.cs.psu.edu (Michael D Mellinger) writes:
>Can someone give me an estimate on how much faster parsing can be made by
>writing a recursive-descent parser instead of using Yacc and Lex? Is there
>enough of a difference to consider using a RDP in a commercial C compiler?
I would tend to believe that table driven parsers (YACC) are faster in
execution than recursive descent parsers. The stack and function call
overhead alone can get to be pretty hairy, especially in deeply recursive
parses.
What is faster, in my experience, is the speed in which you can get a parser
running. Trying to coax a grammer that YACC likes (conflict-free) is
downright a pain, but the recursive descent parser generators I've worked
on/with have much laxer restrictions on the grammar than LR(1). In theory,
one could have a non-deterministic, backtracking RD parser (seen one or two
done in Prolog), but most generators at least require the grammar to be
deterministic (is this the same as LR(1)?
If you want to get a parser up quickly, use an Early's algorithm-based
parser. It will run slow, but it runs the first time, giving you time to
massage the grammar for a faster parser type.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.