[antlr-interest] Re: Heterogeneous AST nodes (was: 2.7.2a4 ANTLR/C# - build ok, panic shutdown)

slightlynew <gackle at shaw.ca> gackle at shaw.ca
Fri Dec 6 17:18:20 PST 2002


Ter,

Ok, I buy all of that.  

What you're saying is consistent with the famous "3 commandments" of 
optimization anyway.  The only way to know for sure if X is slower or 
faster than Y is to measure it.  With that in mind, I will do some 
measuring when I get to the appropriate stage, and in the meantime 
use the factory.

Daniel

--- In antlr-interest at yahoogroups.com, Terence Parr <parrt at j...> 
wrote:
> 
> On Thursday, December 5, 2002, at 09:30  PM, slightlynew wrote:
> 
> >> Perhaps you grabbed 11-29's version not the 30th :)
> >
> > Yeah, or made a dumber error than that!
> >
> > If I do get it to work I'll let you know.  I might just wait for 
the
> > C# version since my work is in C# these days.
> 
> The 30th version has the C# integrated :)  Try it out :)
> 
> >
> > By the way, I have a question about heterogeneous ASTs that 
relates
> > to the "third arg".  From recent posts I gather that the generated
> > code used to do something like this (I'm simplifying here):
> >
> >   ASTNode n = new MyTypeOfNode();
> >
> > and that this has been changed to something like this:
> >
> >   ASTNode n = getASTFactory().createInstance("MyTypeOfNode");
> >
> 
> Yep.
> 
> > Internally, the factory appears to be using reflection to go from 
the
> > string type name to a new object of that type.  (I should qualify
> > that I'm talking about the C# code, and assuming that the Java 
code
> > does something similar.)
> 
> Correct.
> 
> > Isn't creating an object in this way significantly more expensive?
> > If you're creating, say, thousands of nodes of many different 
types,
> > wouldn't one expect slower performance?
> 
> Yes.  Oddly, the java version runs faster than before for 
homogeneous 
> creation (the only real test I had), which I didn't bother to 
> investigate.  It uses the reflection thing too I believe.
> 
> >  Given that the type
> > information *is* known at compile time, why pay the overhead of 
run-
> > time object creation?
> 
> Consistency for one.  Flexibility for two: no point in a factory if 
you 
> don't use ;)
> 
> > This isn't an argument against using a factory.  The factory 
could do
> > a big switch statement (or the equivalent) on the name, like this:
> >
> > case "MyTypeOfNode":
> >   return new MyTypeOfNode();
> 
> I'd have to generate it though.  You are free to build your own 
that 
> does this though.  Literally I tried to add an IF to check for the 
> CommonAST type and then do "new CommonAST" and it was slower!
> 
> > and then resort to the run-time way at the end:
> >
> > default:
> >   return createInstance("MyTypeOfNode");
> >
> > Although, come to think of it, it's not obvious to me exactly what
> > the advantage of the factory approach is in this context?
> 
> Only that you can track or otherwise play with the node creation 
w/o 
> changing the generated code.
> 
> Ter
> --
> Co-founder, http://www.jguru.com
> Creator, ANTLR Parser Generator: http://www.antlr.org
> Lecturer in Comp. Sci., University of San Francisco


 

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



More information about the antlr-interest mailing list