Re: push parser implemenation

[Akim Demaille]

>>> "Bob" == Bob Rossi <address@hidden> writes:

 > On Fri, Apr 07, 2006 at 02:42:29PM +0200, Akim Demaille wrote:
 >> Bob,
 >> 
 >> I'm starting to toy with your implementation, and to try to bench it.
 >> It seems that there is about a 15% performance loss of push.c compared
 >> to yacc.c, both used in pull mode without compiler optimization on my
 >> Mac.

 > You know, it would be possible to only create the structure for the push
 > parser mode, and to leave all variables declared in yyparse for normal
 > mode and for pure mode. This would be more m4 magic, but would fix the
 > performance problems.

 > I wrote it the way it is now because it was cleaner. I only had to do m4
 > magic for 'pv->yychar' vs 'yychar' for the 4 user visible variables
 > (instead of all the variables), because all 3 versions used the structure.

 > What do you think?

I think we should struggle to keep our implementation as simple as
possible, and be ready to trade simplicity against efficiency (to some
extend).

The 15% loss I observed seem acceptable to me, but we should strive to
get rid of them.

If we can't have any better figures with your current set up, then,
yes, the best approach is to add more m4 magic so that push.c used in
plain yacc mode leaves us with the initial performances.



People know that LR parsers are not very efficient, but that's a fair
trade for the flexibility that comes with a parser generator.  My
example, a calculator, is probably the worst case for Bison --- of
course you could have a parser that does nothing but parsing, but is
this case really relevant for genuine uses of Bison? ---, so really,
as of today, I'm confident we could use push.c instead of yacc.c

Still, you seem to experience nastier figures, so we might have to try
harder :(  Or poll our users.  We could also try to bench gcc in
yacc.c or in push.c: I guess you can't tell the difference.