[stringtemplate-interest] StringTemplate Compiler for .NET

[Sam Harwell]

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

 

That aside, I think the idea of compiling templates to an assembly is
great. This is the kind of program that truly makes use of the
multi-language ability at the core of the CLI. I don't have profiling
results from the Java version of StringTemplate to compare with, but
I'll give you an overview of the results of some profiling I did.

 

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).

 

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).

 

Sam

 

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.

 

From: stringtemplate-interest-bounces at antlr.org
[mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Volkan
Ceylan
Sent: Saturday, February 28, 2009 4:44 PM
To: stringtemplate-interest at antlr.org
Subject: [stringtemplate-interest] StringTemplate Compiler for .NET

 

Hello ST lovers,

I met StringTemplate about two years ago and before that i had never
used a templating language (considering my 15+ years coding history, its
a shame :), other than String.Format. Now, i have a CMS developed in
C#/.NET that completely depends on ST to generate pages, where templates
are stored in a SQL database. It is actively being used in some
important web sites in my country. I love the idea behind ST to enforce
model-view separation, which cleared the messy HTML markup from my C#
classes completely, and made it easier to change the look of interface
based on customer requests. I strongly recommend ST to any .NET
developer. Even MS has seen the light and invented MVC framework but
they are a bit late. Anyway, ST can be used as an alternative view
engine in MVC framework too, as the default one doesn't still seem
functional enough to me :)

Nowadays, i am working on a high traffic web site where we expect to
take thousands of requests per second. A page with a rather complex
template (or set of templates) takes about 35 ms (after some
optimizations, it was 130 ms at start) just for
StringTemplate.ToString(). This time doesn't include the time required
to parse a template (templates are parsed and cached, and i'm using
ST.GetInstanceOf()), and it also doesn't include the time for populating
template with data. Fetching all data required in the page from SQL and
setting them in ST takes only 6 ms. 

At first sight, 35 ms may seem a small amount of time, but it means that
only about 25 requests per second can be handled by the web server if we
had just called ST.ToString() to render a page, so the actual requests
per second is even lower.

As i had no intention to give up on StringTemplate, decided to try
writing a compiler for it. I've set up a project in Google code. 

http://code.google.com/p/stringtemplate-dotnet-compiler/

There is a working compiler in SVN repository, but don't expect much
from it. It is only two days of work yet, not even in alpha state.

For now, it can only compile templates like "testing
$a:{$it:{$it:{$it:{$it$}$}$}$}$ $a+b+"blablalalbla"$ $b$ $c$ $d$ end"

No formal arguments, no groups, no format/anchor/null options, no no no,
just what you see above :)

When it comes to speed, for this simple template it works about 5 times
faster than native StringTemplate. I'm expecting the difference to grow
as templates gets more complex. 
Also, there are some room for optimizations, such as inlining simple
template chunks and constant expressions, but my priority is to create a
fully compilant, working compiler.

To keep compiler simple, and easier to develop, i decided not to parse
templates myself, but take a StringTemplate object, walk its chunks and
trees and emit IL code instead of evaluating expressions. For example, i
took ActionEvaluator.cs from ST source code, and replaced evaluation
expressions with dynamic IL generating code. Result can be seen in
ActionCompiler.cs.

I'd appreciate any suggestions, ideas, help etc. Would like to hear from
Terrence (thanks a lot for letting me see the light :), opinion as i
read in the group he also has plans to turn StringTemplate into a code
generating compiler in v4.

Volkan Ceylan









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20090316/bbfe7af9/attachment.html