[stringtemplate-interest] code-generation to "compile" string templates?

[Terence Parr]

Hi Eric,

We have discussed this concept previously. Sam Harwell and others clearly identified the reflection bottleneck. For v4, I'm caching that, which makes it much faster. Oliver Zeigermann is doing some comparison work at the moment:

http://code.google.com/p/jmte/wiki/Comparison

It looks to me like v4 is about 2x faster.  that is partially the cache of the reflection and partially the fact that I'm using a byte code interpreter.

Note that I have not even once tried to make the software more efficient using a profiler. presumably that will get us a little bit faster.

As you say, getting rid of reflection when generating Java byte codes means typing the templates, which is an entanglement factor between model and view. dynamic typing is more flexible. The byte codes obviously would go a lot faster on the job of VM instead of my own because of hotspot compiler. Unfortunately, this means that two reloaded template after a change, you have to be able to unload classes and reload them. that used to be a hassle; not sure where Java is at this point on class reloading.

given the new architecture of the STv4 compiler, it would be fairly straightforward to generate Java byte codes I suppose. Given the dynamic scoping as well that the dynamic typing of ST, we I would definitely not get a one-to-one mapping of byte codes. there would be a bunch of runtime to, for example, look up an attribute up the inheritance chain.

I shouldn't be looking at this at the moment, but perhaps I'll spend a few minutes and look at the profiler today.

Ter


On Jan 30, 2011, at 9:04 PM, Eric B wrote:

> Hi,
> 
> I searched around and could not see if this has been discussed before.  I was curious if the StringTemplate community has discussed compiling templates to Java classes as a means to reduce all the reflection used in resolving extremely dynamic, large templates.  Basically, coders would still use the StringTemplate language to code up the templates.  At runtime, though, instead of resolving tokens using reflection, the templates would go through a one-time process of compiling the template down to bytecode.  The idea would be that the StringTemplate would not have to use reflection to resolve templates like the following:
> someTemplate(person) ::= <<
> <b>$person.address$</b>
> >>
> 
> At runtime, it instead would compile the template to a class that could do it without reflection.   Something like the following...
> public String someTemplate(Person person){
> StringBuilder sb  = new StringBuilder();
> sb.append("<b>").append(person.getAddress()).append("</b>");
> return sb.toString();
> }
> 
> The big downside of not using reflection is that it requires the developer to somehow identify what type of object person is.  
> 
> Other frameworks/libraries make use of this class-generation technique to optimize their runtime.  For examples... JSP transparently compiles down to a Java class and it is that Java class that is used at runtime. Spring uses CGLIB to optimize their AOP proxies http://static.springsource.org/spring/docs/1.2.x/reference/aop.html .  Hibernate makes use of CGLIB... http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html.    JSP is bit different in that it generates physical Java classes on the file system.  Spring simply generates the byte-code in memory.
> 
> Perhaps the StringTemplate syntax could be enhanced so developers could develop "strongly-typed" templates?  These types of templates could make use of a more-optimal code-generation mode.  And the untyped templates would just be interpreted via reflection as they are today.  Just a thought.
> 
> History behind my question... 
> We brought StringTemplate in to our stack a few years ago while doing some maintenance work in our UI code.  At this point, we were on Java 1.4.  Prior to using StringTemplate, much of our HTML was generated in plain Java by appending on to a big StringBuffer.  We did a bunch of research at the time... we selected StringTemplate because it would get our string-building code in to a more maintainable state.  However, after doing this refactor of our UI code out of Java string-building and in to StringTemplate, there was a noticeable drop in response time when the system was under load.  I don't remember the numbers, but using StringTemplate under load was more taxing on our CPU than the prior approach of building up the strings in Java.  When we hooked up a profiler and did some analysis on the before/after refactor behavior, we found the difference was due to the reflection that was used in resolving our StringTemplates.   
> 
> As I recently came across this interest list, I thought I'd pose the question... see if there has been any discussion on the topic.
> 
> Thanks,
> 
> Eric
> 
> 
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest