[antlr-interest] Re: Local lookahead depth
lgcraymer
lgc at mail1.jpl.nasa.gov
Mon Nov 10 16:23:46 PST 2003
Tom--
This isn't an argument about ANTLR internals: Oliver put forth an example for which he thought that tree transformation would be
prohibitive due to lack of memory. It was not a viable example, although he has yet to admit that.
As to performance: there are always tradeoffs between performance and functionality. Sometimes performance wins, sometimes
functionality wins. Chris Leung's LLK (which reminds me, I need to recreate a post--yahoo has Alzheimer's) errs on the side of
performance, while ANTLR 2 errs on the functionality side (copying strings for tokens can be expensive, for example, but it also
allows indefinite length input and editing of token text). There is a reason that Chris sees a factor of five performance difference; at
the same time, I don't think that he is (yet) headed in a direction that will support complex source-to-source transformation. My
experience with large software systems is that local optimization for performance (non-algorithmic) often makes global optimization
difficult, as the code rapidly becomes "unmaintainable", and can limit the potential for extending the system or using it as a building
block in a larger system. The trick is to properly assess the tradeoffs when making design decisions.
--Loring
--- In antlr-interest at yahoogroups.com, "Tom Zagotta" <tzagotta1 at s...> wrote:
> > Do the math. A modern disk drive will sustain a bandwidth of
> > 10-15 MB/s. You have described a problem in which disk usage
> > would be predominantly sequential (one read and one write per
> > pass), and a large fraction of the disk I/O can be overlapped
> > with computation. It is decidedly not a "one hour or ten"
> > issue--the performance differential is unlikely to be more
> > than a few percent, provided that you treat the disk as a
> > block-access device. Besides, between stuff discarded during
> > lexing and stuff discarded during parsing, that 100 MB is
> > likely to shrink into 1-2 MB of tokens and 10-20 MB of syntax tree.
>
> Sorry to interject here -- in my view, performance is always important. If
> I build a parser with ANTLR that takes 10 seconds to parse a file, but my
> competitor's parser takes 3 seconds, then I am in trouble.
>
> ANTLR should have best-in-class runtime performance, in my opinion. We
> shouldn't settle for less, especially for academic reasons.
>
> Best regards,
>
> - Tom
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
More information about the antlr-interest
mailing list