[antlr-interest] Speed (was: build issues: bytecode assembly generation)

Don Caton dcaton at shorelinesoftware.com
Fri Oct 22 22:51:48 PDT 2004


John:

With full optimizations, the entire lexing/parsing/treewalking process is
plenty fast enough.  The pluggable string template thing is very
interesting, but it's too far away to have any impact on our current
development.  I've already modified some of the antlr headers so frequently
called methods can be inlined.  Not sure why those methods weren't already
in the hpp files.

> (D) In real terms, does that 2 seconds vs. 15 seconds really 
> drive your development style into some sort of major dysfunction?

I'm writing a commercial compiler.  If you were the user, recompiling a
project with 10 files, would you rather wait 150 seconds or 20?

There's no dysfunction or complaints here though; the C++ compiler does a
darn good job at optimizing antlr's code, so I'm a happy camper. 

Far as searching the archives, I've been there already, several times.
Yahoo's interface to these groups is horrible.  You can only enter basic
search terms and it only searches through a few hundred messages at a time.
There doesn't even appear to be any way to display messages in threaded
order.  It's just awful.  Do you know if there's an archive maintained
anywhere else besides Yahoo?

Regards,
 
Don Caton
Shoreline Software, Inc.
 

> -----Original Message-----
> From: John D. Mitchell [mailto:johnm-antlr at non.net] 
> Sent: Friday, October 22, 2004 10:55 PM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Speed (was: build issues: bytecode 
> assembly generation)
> 
> 
> >>>>> "Don" == Don Caton <dcaton at shorelinesoftware.com> writes:
> [...]
> 
> > Yes, like parsers <g>.  In a debug build, it takes my 
> antlr-generated
> > (C++) parser about 15 seconds to parse a 77k source file.  
> With full 
> > optimizations enabled, the same code finishes in slightly under 2 
> > seconds.  I'm not kidding.  I was sweating bullets when got 
> my parser 
> > to work and found it was so slow.
> 
> (A) That would be primarily due to slow lexing much more than 
> the parser.
> 
> (B) In Antlr v2.x, if you really need lexing speed, you can 
> always create a flex-based lexer and use that to feed an 
> Antlr-based parser.
> 
> (C) In Antlr v3, the generated the DFAs will be both fast and 
> powerful.  As Ter has mentioned again, the output generation 
> in Antlr v3 is done via pluggable StringTemplates so things 
> like inlining lookahead or not (extra speed vs. code size) 
> will be trivial to change.
> 
> (D) In real terms, does that 2 seconds vs. 15 seconds really 
> drive your development style into some sort of major dysfunction?
> 
> Take care,
> 	John
> 
> P.S.	In terms of why Antlr v2 is written in Java, Ter and I have both
> 	talked about the history of this in the past on this 
> list so, the
> 	curious can search the list archives.
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the antlr-interest mailing list