Re: Why are LR parsers faster than using if conditions

Alex Colvin <alexc@std.com>
11 Jun 2004 02:55:42 -0400

          From comp.compilers

Related articles
Why are LR parsers faster than using if conditions shripal.meghani@philips.com (2004-06-06)
Re: Why are LR parsers faster than using if conditions torbenm@diku.dk (2004-06-09)
Re: Why are LR parsers faster than using if conditions alexc@std.com (Alex Colvin) (2004-06-11)
Re: Why are LR parsers faster than using if conditions cdc@maxnet.co.nz (Carl Cerecke) (2004-06-15)
Re: Why are LR parsers faster than using if conditions cdc@maxnet.co.nz (Carl Cerecke) (2004-06-21)
Re: Why are LR parsers faster than using if conditions t.zielonka@zodiac.mimuw.edu.pl (Tomasz Zielonka) (2004-06-25)
Re: Why are LR parsers faster than using if conditions haberg@matematik.su.se (Hans Aberg) (2004-06-26)
Re: Why are LR parsers faster than using if conditions haberg@matematik.su.se (Hans Aberg) (2004-06-28)
Re: Why are LR parsers faster than using if conditions clint@0lsen.net (Clint Olsen) (2004-06-28)
[5 later articles]
| List of all articles for this month |

From: Alex Colvin <alexc@std.com>
Newsgroups: comp.compilers
Date: 11 Jun 2004 02:55:42 -0400
Organization: The World : www.TheWorld.com : Since 1989
References: 04-06-012 04-06-034
Keywords: parse, LALR
Posted-Date: 11 Jun 2004 02:55:42 EDT

>> Well intuitively I know that LR parsers are fast, they SHOULD be
>> faster than using if then conditions etc. But I was hoping to get
>> some more solid academic reasons to convince a group of people here at
>> my organization...


Perhaps it's because LR parsers are usually implemented using switch ()
{case...} instead of if () ... else... Presumably an LL parser using
switch statements would be about as fast.


It's probably true that it's better to use some sort of formal grammar and
parser generator to produce the cases, rather than code them by hand.




--
mac the naïf


Post a followup to this message

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