[antlr-interest] FEATURE REQUEST: continued and memory/speedissues

Don Caton dcaton at shorelinesoftware.com
Thu Dec 30 09:31:17 PST 2004


> -----Original Message-----
> From: antlr-interest-bounces at antlr.org 
> [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Ric Klaren
> Sent: Thursday, December 30, 2004 10:05 AM
> To: Akhilesh Mritunjai
> Cc: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] FEATURE REQUEST: continued and 
> memory/speedissues
> 
> I can make everything virtual and provide all the rope to 
> potentially hang yourself ;) I guess I'll do that when I'm 
> back at my  home...

Please, NO!  Do something like:

  #define ANTLR_FACTORY_VIRTUAL

  #ifdef ANTLR_FACTORY_VIRTUAL
     #define FACTORY_VIRTUAL virtual
  #else
     #define FATORY_VIRTUAL
  #endif

> Using more inlining might probably increase the memory footprint.
> Results in the past have shown that it really depends on the 
> grammar wether Java/C++ performs better (at least in the past 
> it was like

Actually it's just the opposite in many cases.  Take a look at the code in
CommonAST.cpp.  Virtually all of the methods do nothing other than set or
return the value of the associated member variable.  If these were inlined,
the compiler could optimize them all away.  There's no point at all in
generating a call to getText() when it does nothing more than return the
contents of "text".  If this was inlined, the compiler would just generate
the code to access "text" directly.

The same thing applies to the CommonAST constructors.  They do nothing
except initialize member variables and call the BaseAST() constructor (which
does NOTHING!).  Here again, the compiler could optimize away the
unnecessary calls.  And the call to text("") in the default CommonAST
constructor is unnecessary because text is a std::string and it already
initializes itself.  The compiler could also optimize away the do-nothing
destructor.

BaseAST.cpp is nearly as bad.  The constructors do nothing but call the
AST() constructor, which does nothing except initialize the "ref" member (at
least this one is inline).  

> that) The C++ version has performace issues (but so has the 
> java one) It would take really structural changes to improve 
> things. Inlining changes usually are usually low priority for 
> me. If you can tell me which specific ones are the main 
> problems I'll change them. (I'm low on time so the more 

The C++ version has performance issues because it doesn't allow the compiler
to throw away all the unnecessary code.  The fact that all these unnecessary
calls are virtual method calls just makes it that much worse.  There's no
need for the methods to be virtual if you aren't subclassing CommonAST, so
the virtual keyword should be changed to a #define.

Inlining this stuff actually decreases the memory footprint because you're
eliminating unnecessary code, and as a result it's faster.  Much faster.  I
saw a serious performace increase when I made these simple changes in my
code.  They aren't architectural changes, they're almost trivial.  You're
not really even changing any code, you're just letting the compiler do a
better job.  You could probably do away with most every cpp file in Antlr.
Any decent compiler isn't going to inline large methods, so there's no
drawback.  And you eliminate the problems of building a runtime DLL.

Don




More information about the antlr-interest mailing list