[antlr-interest] Re: Performance Issues

[Bryan Ewbank]

All,


An update on my performance issues.  Thanks for all the responses!

We've found two measurable improvements (C++)

(1) Replace => predicates with {}? predicates.  THIS IS HUGE

We'd done quite a bit of this before, but we got much more aggressive.
 Specifically, replace something like this:
  ( asgn ) => foo
with this equivalent
  { is_asgn(_t) }? foo
and is_asgn is defined something like this (hope the parens are correct):

  is_asgn!
  returns [bool match_asgn=false]
  :
    ( { _t->getType() == STMT }?
      #( STMT
        ( { _t->getType() == EXPR }?
          #( EXPR
            ( { _t->getType() == ASGN }?
              ASGN
                { match_asgn=true; }
            | . )
          )
        | . )
      )
    | . )
  ;

I suspect there's a more concise way to do this, but this is what
seems to work.  Any suggestions?

(2) Drive to "buildAST=false"  MEASURABLE

We had several passes that mutate specific nodes IN PLACE.  This is
now done with a tree walker using buildAST=false, rather than with a
tree copier (buildAST=true).  By itself, for one pass, not much. 
Systematically, okay.

More if we learn anything else.

On 10/21/05, Bryan Ewbank <ewbank at gmail.com> wrote:
> I've been having some discussions with the "powers that be" where I
> work regarding whether ANTLR is up to the task we have set before it.
> We have it working (lex scanner; ANTLR parser, multiple tree parsers,
> C++/linux), but the performance is pretty bad (~3 seconds to clone the
> AST for a 10K line input file for a C-like language).  A first quick
> glance at gprof doesn't show any obvious outliers or idiocies;
> however, I know there's more to be done with profiling.
>
> I got the impression, several times, that people were pleased with the
> thruput of ANTLR for parsing and tree transformations.  Yes, there are
> a few "classic" tunings required - I'm working thru the information
> from this list over the past few yearse - but still...
>
> Our productivity is certainly higher with ANTLR, particularly for the
> tree-parsers; however, if customer perceived thruput is "bad"
> (whatever that means, right :-), it's a serious problem.
>
> So, has anyone been holding out on tunings, optimizations, and
> outright tricks that they are using to get ANTLR to eat trees faster?
> Again, I'm in the C++ world, so java suggestions don't help.
>
> Thanks from a harried ANTLRite,
> - Bryan Ewbank
>