[stringtemplate-interest] StringTemplate Compiler for .NET

[Johannes Luber]

> My C# port is checked into Perforce under
> //depot/code/antlrcs/main/Antlr3.StringTemplate/. I submitted the cache optimization in CL5887. You are
> correct about the debugging difficulty of dynamic methods. I'll see about
> using them as stubs to accessing the properties, since it should be very easy.
> Good luck with the conversion and I look forward to seeing the progress. :)
> 
> Sam

Sam, can you publish an official (beta?) of ST# 3.2? Then I can update the ANTLR distribution.

Johannes

P.S.: There is another mail on this list, which you should reply to. The question is if your port is still ASCII limited or accepts unicode.
> 
> -----Original Message-----
> From: stringtemplate-interest-bounces at antlr.org
> [mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Volkan Ceylan
> Sent: Tuesday, March 17, 2009 3:52 AM
> To: stringtemplate-interest at antlr.org
> Subject: [stringtemplate-interest] StringTemplate Compiler for .NET
> 
> > 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 :(
> _______________________________________________
> 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

-- 
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschützt?
Jetzt informieren und absichern: https://homebanking.web.de/?mc=mail@footer.