[stringtemplate-interest] it's 60% of time in ObjectModelAdaptor.getProperty()

[Oliver Zeigermann]

Compiling does not bring much without static typing. Caching the
internal data structure (e.g. AST or custom byte code) at least for me
was almost as fast as compiling to byte code. But with static types
you could be as fast as hand written Java code.

Generating bytecode directly or first creating source and then
compiling it should both work. Generating bytecode certainly is faster
(not for runtime, just compile time), but generating source should be
easier to do and maintain.

You would probably use javax.tools.JavaCompiler instead to avoid
dependencies to the JDK installed and then you do not need that
tools.jar.

E.g.

JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();

Just my 5 cents.

- Oliver

2011/2/5 Terence Parr <parrt at cs.usfca.edu>:
> yeah,I like the idea a lot too, but I'm also worried about the tools.jar thing.
>
> when it comes down to it, ST v3 was the fastest in the world but it worked for most people. STv4 is at least two times faster so I think perhaps we can just leave it is as-is for now. The easier thing to do might be to generate Java code from the templates and give people a jar to include in their application. The only problem is dynamic  field and method eval is still there. without static types, I'm not sure there's a real reason to add the complexity of generating java.
>
> Ter
>
> On Feb 4, 2011, at 2:18 PM, Collin Fagan wrote:
>
>> Ahh yes the compiler API, it's very cool. I remember experimenting with this to do something similar to what you want, I was implementing a simple interface that just returned a value and it was faster then reflection at the time. I would warn though that using tools.jar in an application is not a simple matter. tools.jar comes with a JDK because it is bound to that jdk. As an example my current application uses JMX dynamic attach, also in tools.jar. We have to compile against one tools.jar and then add the jdk's tools.jar at run time to the classpath at install time. This is becouse tools.jar has platform dependent code in it, or it refrences platform dependand libraries. It's possible that the compiler API uses nothing of the native libraries and that it might work to include tools.jar as a part of ST, but I wouldn't count on it. ASM, cglib, and javasist all try to do the same kinds of things... just in a more verbose way that I've never been able to get my head around co
>  mpletely yet.
>>
>> I really like the idea though.
>>
>> Collin
>>
>> On Fri, Feb 4, 2011 at 3:58 PM, Terence Parr <parrt at cs.usfca.edu> wrote:
>>
>> On Feb 4, 2011, at 1:55 PM, Terence Parr wrote:
>>
>> > great info. i remember you told me a while back.
>> >
>> > i wonder how easy this is in java using ASM or whatever.  i'd have to generate stubs and then figure out how to load. it's a solved problem but i wonder if there is a simple example.
>>
>> looks easy enough:
>>
>> http://www.javaworld.com/javaworld/jw-06-2006/jw-0612-dynamic.html?page=3
>>
>> Ter
>>
>> _______________________________________________
>> stringtemplate-interest mailing list
>> stringtemplate-interest at antlr.org
>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>>
>
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>