[stringtemplate-interest] StringTemplate Compiler for .NET

[Volkan Ceylan]

> I’m extremely interested to see how the compiled code performs compared
> to my C# port of StringTemplate.

 Hi, is your C# port open source? Would like to see what optimizations
you did. I'm currently working on public 3.1beta at stringtemplate.org

> That aside, I think the idea of compiling templates to an assembly is great.

Actually, i'm not thinking about compiling to an assembly, but to
dynamic methods. AFAIK, due to some problems with .NET, when you load
an assembly, there is no way to unload it, unless you use a separate
application domain to load assemblies, and unload the domain
completely.

Dynamic methods can be garbage collected when you have no delegates or
references to them. That's why i prefer dynamic methods versus
assemblies. The only problem with dynamic methods i see is that they
are harder to debug :(

>I used a sampling method to profile the library. The test was a batch conversion
> of the 8 grammars that are used in the C# port of the ANTLR >Tool. 54.33% (inclusive)
> of the samples were in Antlr3.StringTemplate.dll. Only 6.59% (inclusive) was spent
> in >ASTExpr.rawGetObjectProperty, which is responsible for all measurable uses of .NET reflection.
> 35.31% (inclusive) of the time was spent in >ActionEvaluator.action,
> (note: this call encapsulates all calls to ASTExpr.rawGetObjectProperty).

ActionEvaluator.action is walking a tree and consists of some costly
CASE statements. When a template is compiled, there will not be any of
them in the generated IL. Currently i'm having about 10x speed for
simple templates.


> By implementing a System.Type -> System.Reflection.MemberInfo map in ASTExpr and
> caching the property accessors, I was able to reduce the time spent in
> ASTExpr.rawGetObjectProperty to 2.36% (inclusive).

This is a nice idea, would like to see implementation. There may be
even a further improvement by compiling property accessors as dynamic
methods such as (type, property) -> dynamic get delegate (though i'm
not %100 sure about that, need to see source code of new DLR)

> PS: I’ve thought about doing something similar to the CLI compilation with
> ANTLR grammars, but profiling the generated code has shown that it’s not the bottleneck right now.

I don't know much about ANTLR and its grammars, other than a general
overview of what it is used for :(