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

[Ric Klaren]

On Thu, 30 Dec 2004 12:31:17 -0500, Don Caton
<dcaton at shorelinesoftware.com> wrote:
> Please, NO!  Do something like:
> 
>   #define ANTLR_FACTORY_VIRTUAL
> 
>   #ifdef ANTLR_FACTORY_VIRTUAL
>      #define FACTORY_VIRTUAL virtual
>   #else
>      #define FATORY_VIRTUAL
>   #endif

Not really to my taste to add. Doing stuff like this is the start of
something that's a bother to maintain. Adding a number of virtuals is
no problem. If you need this I suggest making a vendor branch or
something. In the end we'll end up with a define per class or worse.

> > 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).

I'll have a look at these.

> > 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.

The #define thing is not an option for me..

In general my approach to antlr maintenance is simple:
1. fix bugs
2. make sure functionality that's there works as advertised, still a
lot to be done there.
3. user request.
4. optimization/speed.

Combine that with the fact that I'm limited in time I can spend on
antlr makes things simple optimization stuff goes last period. The
last year has been very busy for me jobwise and next will probably be
even busier for a while due to jobswitching and moving, even now I
*should* be doing other stuff than antlr stuff....

If you want speed wait for antlr3. There I'll get the chance to design
things completely from the bottom up and also with speed in mind. And
to be honest I'd rather spend the little time I have on that than on
the antlr 2 support lib. The current lib is just a direct java to C++
port and it shows.

Cheers,

Ric