[antlr-interest] Re: Local lookahead depth

[lgcraymer]

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/