Compile Mustache -> ColdFusion

[markmandel]

Starting up an issue, so we can discuss implementation, as I've been thinking about this a lot.

The issue with converting mustache is that what sections and variables do at runtime differ depending on what the variable is at runtime.

So the way I see this working is that each {{#section}} would need to be converted to a function (probably one that allowed for output to make life super easy). That way you could do type checking at run time to determine what the type of the object is, and then react accordingly.

You would need to store the inner parts of the original mustache template, so it can be passed to lamda's as well.

Anyone see any major issues with that sort of implementation?

[rip747]

forgive me for being stupid, but i'm trying to wrap my head around all of this. what i'm trying to understand is what is the primary goal? is it to cache the compilation of the templates?

[markmandel]

Reasons:

1. Should be faster
2. Shouldn't have to be regexing strings on every request
3. Shouldn't have to be doing string replacement on every request (CF can do that for us already).
4. Shouldn't need a rendering engine on top of a rendering engine.

[dswitzer]

@rip747

The goal (as I see it) would be to see if we can get better performance out of the template by compiling the template done to something that can be either interpreted faster or as @markmandel indicated could be converted to something executable.

While the current code runs pretty well, I'm not sure it's well suited for when you have to run the same template in a batch that might include tens of thousands of executions.

Since ColdFusion isn't great and dynamically building and executing code, I'm wondering if it would make more sense to compile a template to some kind of token array that we could process quickly.

I'm thinking something that would look something like:

[
  {
    fn // reference to a function to run
    args: // arguments to pass to the function
  }
]

We could then just loop over the array and run each function passing in the arguments needed. The functions specified would either be the lamba or internal mustache functions designed to handle the logic (some of the functions would just be returning the text as-is.) The goal would be to great something that can be looped through and processed quickly.

I'm just wondering if we'll be able to squeeze better performance out of compilation in most use cases. My guess is the use cases of a ColdFusion-based Mustache implementation are greatly different than those looking for Java or JavaScript implementations (which are more likely to executed many times during the course of the code.) I suspect most CF-based uses are for simpler needs (other than maybe as used for e-mail templates--which would be executed many times in a mail merge type operation.)

[markmandel]

The only question I have is:

Why should we do all this work ourselves, when we could convert it to CFML and have the CFML engine do exactly this work for us?

(Also - as of next week, we'll be using Mustache as the main rendering language on our site, so the closer to the metal the template language is, the better, IMHO)

[dswitzer]

@markmandel

I have several concerns (that may end up being invalid) about converting to CFML:

1. The overhead of compiling. In my (admittedly limited) experience compiling CFML on the fly for execution is there's overhead. The point of compiling should be to gain performance benefits. To avoid cached templates issues, we'd probably need to end up creating CFML files w/a hash of the template string--which has some overhead in itself.
2. Evaluation issues. As you mentioned, we'd probably need to end up generating a CFC that gets initiated to protect from variable/namespace collisions (rather than trying to the dynamic template.)
3. Managing compiled CFML. We'd need to do something to manage the cache of files we create. IMO, the benefit of compiling would be the ability to re-use the compiled template, which means we need to do something to clean up the unused template cache. We could delete the template after use, but then that means we're losing the benefit of re-using the compiled template.
4. I'd eventually like to implement a Mustache factory which would load as a singleton and pre-cache all our templates for use (we're going to use Mustache for all our various e-mail notifications, which is a big part of our application.) So I ideally want a compilation strategy that works will with workflow. So, to pre-compile in a singleton, we'd definitely need to keep the compiled templates on the filesystem, which just means # 3 (deleting old templates) becomes important.

This is where closures would potentially rock--being able to generate code on the fly and and store it in memory.

Anyway, I'm sure this issues can be worked through.

The main thing to me is are we really gaining performance benefits for the majority of use cases by compiling? I guess we can make compilation an option if it's slower on single runs, with the ability to specifying the results of the compile() method in place of a template.

We probably ought to mock up some code to see what we're really looking at.

What do you guys think?

[markmandel]

I have to respectfully disagree with all of your points Dan,

Re: The overhead of compiling:
That is an overhead you experience once, and then the file is stored on the file system, with a name that is a hash of the mustache string. Once it has been compiled you never have to have the overhead ever again. On a production system, the file is stored in the CFML engine template cache, so overhead is the same overhead as almost any CFML template.

Oh, and 9/10 times, I'm sure you'll generate this file on your dev/stage server, and then push it up to your production system. So the production system wouldn't even see the compilation overhead.

Hashing strings is not particularly slow, but if you are concerned about it, let's cache the hashing against the string key. Very little overhead that way. Far less memory overhead than caching entire AST's in memory, and far les CPU than looping around them over and over for every invocation.

Also far less overhead than managing that cache of ASTs, especially when the CFML engine already does this for us - with no extra work on our end, and far less risk of memory leaks (which I've already run into).

Re: Evaluation issues:
Do the cfinclude inside a cfmodule call. Variable safe, and very fast.

Re: Managing compiled CFML:
Why do we need to have something to manage the cache of files, if they are hashed against the mustache string (i.e. are unique)? Disk space is cheap, and they are very small files. If you are at all concerned, delete them all on occasion from your dev/stage server, and make sure your prod server syncs up with that particular versions incarnation. rsync -r --delete solves this issue.

Re: *I'd eventually like to implement a Mustache factory which would load as a singleton and pre-cache all our templates *
Again, why re-implement the CF engine template cache? It already exists, and it's proven. Why re-invent the wheel?

Re: This is where closures would potentially rock:
Not following you on this one. I don't see how these help. You would still need to write the code to somewhere before executing it. Unless you start caching a bunch of ASTs.. and then we get back to "why would you re-invent the CFML engine template cache?"

To be honest, I can't see how a layer on top of CFML could ever be faster than straight CFML? It doesn't make any sense to me.

[dswitzer]

@markmandel

Like I said, my concerns may be invalid. Just listing them for context and conversation purposes.

I never said that running straight CFML was faster than running something interpreted. My concern was with the compiling into CFML and then invocation for single run templates, that might end up being slower.

We also plan on allowing our customers to leverage Mustache for customizing their outbound messages--which is why I'm thinking about management of compiled code. We have the potential for massive amounts of templates, some of which will rarely (or potentially never) be called.

I just like the way the compilation stuff works in many of the JS libraries. The compilation ends creating a closure, which can be passed around in memory and run. I like the idea of being able to compile the template when you need the evaluation benefit, but the compile code doesn't have to be managed on disk.

For us, something like this is going to be a fairly common use case:

var template = Mustache.compile(template);

for( var i=0; i < 10000; i++ ){
  Mustache.render(template, context[i]);
}

The problem is the "template" may only ever be used the one time (or very infrequently.) Keeping it around on disk makes no sense. If the compiled template is purely in memory, there's nothing else to manage.

Anyway, we could always add methods for removing a compiled template from disk. Just giving some context in to my line of thinking.

Also, if we compile the template to CFML, wouldn't it be most efficient to just generate straight procedural code, where sections/partials are just conditional blocks that have been fully compiled?

We'd just have to be aware of caching issues due to partials that were changed, but it would be manageable.

[rip747]

if you use closures then Mustache will require CF9. Currently Mustache is
targeted at CF8.01. I would like it to remain at CF8.01 if at all possible
since some of my project that are on CF8.01 are still using it.

On Mon, Apr 9, 2012 at 9:17 AM, Dan G. Switzer, II <
reply@reply.github.com

wrote:

@markmandel

Like I said, my concerns may be invalid. Just listing them for context and
conversation purposes.

I never said that running straight CFML was faster than running something
interpreted. My concern was with the compiling into CFML and then
invocation for single run templates, that might end up being slower.

We also plan on allowing our customers to leverage Mustache for
customizing their outbound messages--which is why I'm thinking about
management of compiled code. We have the potential for massive amounts of
templates, some of which will rarely (or potentially never) be called.

I just like the way the compilation stuff works in many of the JS
libraries. The compilation ends creating a closure, which can be passed
around in memory and run. I like the idea of being able to compile the
template when you need the evaluation benefit, but the compile code doesn't
have to be managed on disk.

For us, something like this is going to be a fairly common use case:

var template = Mustache.compile(template);

for( var i=0; i < 10000; i++ ){
 Mustache.render(template, context[i]);
}

The problem is the "template" may only ever be used the one time (or very
infrequently.) Keeping it around on disk makes no sense. If the compiled
template is purely in memory, there's nothing else to manage.

Anyway, we could always add methods for removing a compiled template from
disk. Just giving some context in to my line of thinking.

Also, if we compile the template to CFML, wouldn't it be most efficient to
just generate straight procedural code, where sections/partials are just
conditional blocks that have been fully compiled?

We'd just have to be aware of caching issues due to partials that were
changed, but it would be manageable.

---

Reply to this email directly or view it on GitHub:
#7 (comment)

[dswitzer]

@rip747

We're still using CF8.01 as well. I should have left that comment off, it was more of a "I wish CF had introduced closures long before CF10" statement, but that's certainly not clear from my message. It was definitely not an intention of mine to suggest we target CF10.

[rip747]

all is cool. i even screwed up by stating that closures are in ACF9 instead of ACF10 :P

[markmandel]

Re: * The problem is the "template" may only ever be used the one time (or very infrequently.) Keeping it around on disk makes no sense. If the compiled template is purely in memory, there's nothing else to manage. *

Actually, you very much have to manage how many templates are in memory. If you are letting people throw in templates as they see fit, you will need to manage what templates are stored in memory, and for how long. This is a big concern for memory leaks.

Even for what you are talking about (1 template, thousands of iterations), you're talking about an extra overhead of 2 file I/O operations. (1) write to disk (2) read from disk. I'd take that over implementing my own memory management solution. Once the file has been read in by the CFML engine template cache, the overhead at that point is minimal, as it's the CFML template cache. I can't see how that would be slower.

The only time I can think it may well be slower, is if it was single use, single iteration - in that case, I would say - use the Virtual Disk to compile the template, rather than the physical disk. (Unless you're on 8.01). Is this something you would have a use case for? (It's very far removed from mine - we're pretty much replacing CFML templates with mustache ones).

I see your point re: * We have the potential for massive amounts of templates * - but I would still err on the side of cleaning up the disk, which is much harder to fill up, than RAM, which is much easier. Failing that - compile your mustache template to the Virtual Disk, and everyone should be happy at that point :)

Re: Also, if we compile the template to CFML, wouldn't it be most efficient to just generate straight procedural code, where sections/partials are just conditional blocks that have been fully compiled?
I assume this refers to my original point above, where I said: "So the way I see this working is that each {{#section}} would need to be converted to a function...".

I can't see how you could generate this compiled cfml into straight procedural code. You can't replace a {{#section}} with a or a or a - because it can change at run time, depending on the context. Hence the idea of converting each section into a function, that can then (probably with some helper function's help) do the appropriate thing depending on the data coming in. It's the only way I can see it working (at least in my head). I'm open to other design ideas though.

[dswitzer]

@markmandel:

On 4/9/2012 6:56 PM, Mark Mandel wrote:

Re: * The problem is the "template" may only ever be used the one
time (or very infrequently.) Keeping it around on disk makes no
sense. If the compiled template is purely in memory, there's nothing
else to manage. *

Actually, you very much have to manage how many templates are in
memory. If you are letting people throw in templates as they see fit,
you will need to manage what templates are stored in memory, and for
how long. This is a big concern for memory leaks.

When I said keeping it in memory, I wasn't talking about storing as a
singleton or storing in a persistent scope. I was referring to a
compiled template that only lived the life of the current request--where
GC should clean it up.

Even for what you are talking about (1 template, thousands of
iterations), you're talking about an extra overhead of 2 file I/O
operations. (1) write to disk (2) read from disk. I'd take that over
implementing my own memory management solution. Once the file has
been read in by the CFML engine template cache, the overhead at that
point is minimal, as it's the CFML template cache. I can't see how
that would be slower.

The only time I can think it may well be slower, is if it was single
use, single iteration - in that case, I would say - use the Virtual
Disk to compile the template, rather than the physical disk. (Unless
you're on 8.01). Is this something you would have a use case for?
(It's very far removed from mine - we're pretty much replacing CFML
templates with mustache ones).

I wasn't trying to imply that all compiled templates should be stored in
some kind of persistent scope. Ideally I'd have a factory where my core
templates are persisted (which consist of a very known, limited number
of templates) and then rest are compiled as needed.

However, it's all a moot point if the goal is to compile to CFML as we
have no way to native render to memory in CF8.01 (which is definitely a
requirement of mine.)

For me, my use case is often closer to single use, single iteration.
While it's likely the template is used more than once in it's lifetime,
there are many use cases were it's used so infrequently (with the
potential of it never being used again) that I'd rather handle it as a
single use/iteration.

These templates will be mainly pretty simple and from my testing
generally already run < 15ms, so for me these type of operations don't
gain from really compilation.

Maybe the best option for now is to have the compile() compile to CFML
and return a struct w/information on the compiled template.

The render() method would look at the "template" argument and if it's a
struct, would then try to execute the compiled template.

NOTE: I'd have the compile() return a complex variable, that way it
doesn't leave potential security holes. If we just returned a string
path, then that would leave a user-defined template open to exploits.

I see your point re: * We have the potential for massive amounts of
templates * - but I would still err on the side of cleaning up the
disk, which is much harder to fill up, than RAM, which is much
easier. Failing that - compile your mustache template to the Virtual
Disk, and everyone should be happy at that point :)

The project I'm working on is for CF8.01, so the virtual disk is not an
option.

I'm almost wondering if it makes sense to support both a compiled method
and the current interrupted code. That way you can utilize compiled
templates if it makes sense, but don't need to compile all your templates.

For me, it would make sense to be able to pre-compile some of my
templates--from which I have a handful of core templates that will be
re-used over and over.

However, I also have a bunch of templates that may only be used once or
rarely used. For those templates, keeping a persistent cache on disk
doesn't make a lot of sense. We could certainly build management into
the CFC, but it certainly adds a lot of complexity.

All I'm saying is I think there are times when I don't think it makes
sense making a compile template persistent on disk. It works very well
for some use cases, but not for all.

Re: Also, if we compile the template to CFML, wouldn't it be most
efficient to just generate straight procedural code, where
sections/partials are just conditional blocks that have been fully
compiled? I assume this refers to my original point above, where I
said: "So the way I see this working is that each {{#section}} would
need to be converted to a function...".

I can't see how you could generate this compiled cfml into straight
procedural code. You can't replace a {{#section}} with a or
a or a - because it can change at run time,
depending on the context. Hence the idea of converting each section
into a function, that can then (probably with some helper function's
help) do the appropriate thing depending on the data coming in. It's
the only way I can see it working (at least in my head). I'm open to
other design ideas though.

I was imagining the compiler might end up producing something like for
sections:

<cfif isStruct(...)>
<cfelseif isArray(...)>
<cfelseif isFunction(...)>

Maybe helper functions would be better, I was just thinking about trying
to make the compiler produce code that was the most linear as
possible--which I assumed might be the most efficient.

I don't really care how it's ultimately done, just thinking that we
should have the results produce the fastest code we can (since the
ultimate goal is speed.) This was just an idea.